API marketplace

Interference (press and shrink) fit engineering maths as an API, computed locally and deterministically from the Lamé thick-wall equations — the contact-pressure, holding-capacity and assembly-temperature numbers a mechanical designer or machinist sizes a shaft-and-hub joint with. The pressure endpoint gives the contact pressure that builds at the interface from the diametral interference, the shaft and hub diameters and the elastic modulus, plus the tensile hoop stress at the hub bore — the highest stress in the joint, which a thin hub can split if it exceeds the yield: a 50 mm solid steel shaft in a 100 mm hub with 0.05 mm interference makes about 75 MPa of contact pressure and 125 MPa of bore hoop stress, and doubling the interference doubles the pressure. The holding endpoint turns that pressure into the axial push-out force and the transmissible torque through the friction at the interface (force = pressure × contact area × friction, torque = force × shaft radius), the figures that decide whether the joint slips under load. The assembly-temperature endpoint gives the heating (hub) or cooling (shaft) temperature change for a shrink fit — ΔT = (interference + clearance) ÷ (α × diameter) — so the part slides on freely and grips as it returns to temperature. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical-design and machine-building tools, manufacturing and CAD utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Same-material Lamé estimates — verify against the material yield with a safety factor. 3 compute endpoints. For thin-wall pressure-vessel stress use a pressure-vessel API.

Uptime

100.0%

Latency

71ms

Subs

3,435

Ship initial-stability maths as an API, computed locally and deterministically — the metacentric-height, righting-moment and rolling-period numbers a naval architect, ship officer or marine-surveyor judges a vessel by. The metacentric-height endpoint gives GM = KM − KG, the single most important stability figure: the height of the metacentre (set by the hull form and draught) above the centre of gravity (set by how the ship is loaded), with a classification from a dangerous negative GM, through tender and comfortable, to a stiff GM that rolls violently — naval architects aim for the middle, because too little is unsafe and too much is hard on cargo and crew. The righting-moment endpoint gives the small-angle righting arm GZ ≈ GM · sin(heel) and the righting moment (GZ × displacement) that pushes the ship back upright, valid up to roughly 7–10° before the true GZ curve bends away. The roll-period endpoint gives the natural transverse rolling period T = 2π·k / √(g·GM) from the GM and beam — the same relation sailors run in reverse as the rolling-period test, where a suddenly longer roll warns that GM has dropped. Everything is computed locally and deterministically, so it is instant and private. Ideal for naval-architecture and ship-design tools, marine-surveyor and loading-software utilities, maritime-training apps and stability dashboards. Pure local computation — no key, no third-party service, instant. Initial-stability estimates — use full KN cross-curves for large angles. 3 compute endpoints. For hull speed and design ratios use a sailing API.

Uptime

100.0%

Latency

81ms

Subs

3,377

Apparent ("feels-like") temperature maths as an API, computed locally and deterministically from the official meteorological formulas — the three indices a weather app, dashboard or safety tool reports alongside the raw thermometer reading. The heat-index endpoint gives the US National Weather Service heat index from the air temperature and relative humidity using the full Rothfusz regression with its low- and high-humidity adjustments: because high humidity stops sweat evaporating, the body cannot shed heat and it feels far hotter than the thermometer — 90 °F at 70 % humidity feels like about 106 °F — and the result comes with a risk category from caution through danger to extreme danger. The wind-chill endpoint gives the 2001 NWS / Environment Canada wind chill from the temperature and wind speed, the cold-weather counterpart, with the frostbite-time risk band — 0 °F in a 15 mph wind feels like about −19 °F. The humidex endpoint gives Canada's warm-weather index from the temperature and humidity on the same Celsius scale, derived through the water-vapour pressure. Everything is returned in both °F and °C and computed locally and deterministically, so it is instant and private. Ideal for weather and outdoor apps, occupational-safety and sports tools, smart-home and HVAC dashboards, and climate and health utilities. Pure local computation — no key, no third-party service, instant. Human-comfort estimates in shade and light wind. 3 compute endpoints. For dew point and moist-air properties use a psychrometric API; for live conditions a weather API.

Uptime

100.0%

Latency

68ms

Subs

4,322

Aviation atmosphere maths as an API, computed locally and deterministically using the exact International Standard Atmosphere relations — the numbers a pilot, dispatcher or flight-planning tool needs before take-off, not a rough rule of thumb. The density-altitude endpoint turns the field elevation, altimeter setting and outside air temperature into the pressure altitude (elevation + (29.92 − setting) × 1000) and then the density altitude — the altitude the air actually feels like to the wings and engine — computed from the true ISA density ratio rather than the approximate 120-foot-per-degree rule, with the ISA temperature deviation: on a hot, high day the density altitude soars, robbing lift and thrust and lengthening the take-off roll, the classic mountain-airport hazard. The true-airspeed endpoint gives TAS from calibrated airspeed as CAS ÷ √(density ratio), so the navigator gets the real speed through the air that climbs above the indicated reading with altitude and temperature. The isa endpoint returns the standard-atmosphere temperature, pressure, pressure and density ratios and the speed of sound at any altitude in the troposphere — the reference every altimeter, performance chart and engine rating is built on. Everything is computed locally and deterministically, so it is instant and private. Ideal for flight-planning and EFB apps, drone and UAV tools, aviation weather dashboards, and aerospace-engineering utilities. Pure local computation — no key, no third-party service, instant. Troposphere (≤ 36,089 ft); incompressible TAS. 3 compute endpoints. For the speed of sound and Mach use a Mach-number API; for runway wind components a crosswind API.

Uptime

100.0%

Latency

78ms

Subs

3,968

Quarter-mile drag-strip maths as an API, computed locally and deterministically — the classic empirical estimates a racer, tuner or car enthusiast uses to relate a car's power and weight to its performance. The et endpoint gives the predicted elapsed time and trap speed from flywheel horsepower and race weight using the standard formulas — ET = 5.825 × (weight ÷ hp) raised to the one-third, trap speed = 234 × (hp ÷ weight) raised to the one-third — so a 3,000 lb car with 300 hp is predicted to run about 12.6 seconds at 109 mph, assuming a competent launch and decent traction. The horsepower endpoint runs it in reverse: because trap speed is set by power-to-weight and barely by the launch, hp ≈ weight × (trap ÷ 234) cubed is a popular way to estimate flywheel power straight off a timeslip. The power-to-weight endpoint gives the ratio that actually decides acceleration — in horsepower per pound, horsepower per ton and watts per kilogram, the cleanest cross-unit figure — with a performance class from commuter through hot hatch and supercar to hypercar, because a light 200 hp car can beat a heavy 400 hp one. Everything is computed locally and deterministically, so it is instant and private. Ideal for drag-racing and tuner apps, car-spec and comparison tools, automotive enthusiasts and motorsport dashboards. Pure local computation — no key, no third-party service, instant. Empirical estimates assuming a good launch and traction — not a timeslip. 3 compute endpoints. For aerodynamic drag use a drag API; for gearing use a gear-ratio API.

Uptime

100.0%

Latency

78ms

Subs

3,361

Heat-pump and refrigeration performance maths as an API, computed locally and deterministically — the efficiency numbers an HVAC engineer, energy auditor or heat-pump installer actually works with. The cop endpoint gives the coefficient of performance and the US EER rating from the thermal capacity and the electrical power: a unit moving 7 kW of heat on 2 kW of electricity has a COP of 3.5 (an EER of 12), meaning 3.5 units of heating or cooling for every unit of electricity — which is why a heat pump beats resistance heating, where the COP is exactly 1. The carnot endpoint gives the unbeatable ideal limit set only by the absolute temperatures — heating = Th ÷ (Th − Tc), cooling = Tc ÷ (Th − Tc) in kelvin, where heating COP always equals cooling COP plus one — and, given a real COP, the second-law efficiency that says how close the machine runs to that ceiling; the smaller the temperature lift, the higher the limit, which is why ground-source and low-temperature systems beat air-source on a cold day. The capacity endpoint turns electrical power and a COP into the delivered heating or cooling in kilowatts, BTU per hour and tons of refrigeration — the extra energy over the electricity is pulled from the outside air, ground or water. Everything is computed locally and deterministically, so it is instant and private. Ideal for HVAC and refrigeration engineers, energy auditors, heat-pump and building-performance tools, and sustainability dashboards. Pure local computation — no key, no third-party service, instant. Estimates at the stated conditions — real COP falls as the temperature lift rises. 3 compute endpoints. For room sizing use an HVAC BTU API; for moist-air properties use a psychrometric API.

Uptime

100.0%

Latency

72ms

Subs

3,895

Steam-boiler engineering maths as an API, computed locally and deterministically — the three numbers a boiler operator, plant engineer or steam-system designer actually works with. The boiler-hp endpoint converts a required heat output into boiler horsepower (heat ÷ 33,475 BTU/hr, the standard definition), the equivalent steam output in pounds per hour "from and at" 212 °F (34.5 lb/hr per BHP) and the output in kilowatts — a 1,000,000 BTU/hr load is about 29.9 BHP or 1,031 lb/hr of steam. The factor-of-evaporation endpoint gives the real capacity for your feedwater: the factor = (the total heat of the steam − the feedwater heat) ÷ 970.3, always greater than one because the boiler must add the sensible heat to bring water up to boiling, so a boiler rated "from and at" 212 °F actually makes less with 60 °F feedwater — which is exactly why preheating feedwater with an economiser raises capacity and saves fuel. The blowdown endpoint gives the continuous blowdown rate to hold the boiler water within its dissolved-solids limit: blowdown = steam × feedwater TDS ÷ (boiler limit − feedwater TDS), with the cycles of concentration and the blowdown as a percentage of feedwater — better feedwater means more cycles, less blowdown and less wasted hot water. Everything is computed locally and deterministically, so it is instant and private. Ideal for boiler operators, steam-plant and HVAC engineers, energy auditors, water-treatment specialists and process-engineering tools. Pure local computation — no key, no third-party service, instant. Engineering estimates — verify against the manufacturer data and local code. 3 compute endpoints. For moist-air properties use a psychrometric API; for compressed air use a compressor API.

Uptime

100.0%

Latency

71ms

Subs

4,507

Electric-vehicle charging maths as an API, computed locally and deterministically — the three numbers every EV driver and charging app actually needs. The charge-time endpoint gives how long a session takes: from the battery size and the gap between the starting and target state of charge it works out the energy to add and the time at a given charger power and efficiency — a 60 kWh battery from 20 % to 80 % on a 7.2 kW home charger at 90 % efficiency takes about 5.6 hours, and it reminds you that DC fast charging slows sharply above 80 % so road trips should be planned around the fast part of the curve. The range-added endpoint turns a charging session into miles: from the charger power, the minutes plugged in and the car's miles per kWh it gives the energy and range added, plus the handy "miles per hour of charging" figure — a 7 kW home charger adds roughly 22 mi/hr, a 150 kW DC station hundreds. The cost endpoint gives what a charge costs, correctly billing the energy drawn from the grid (the energy to the battery divided by the charging efficiency) times the price per kWh, with the effective cost per usable kWh — home overnight rates make EV miles very cheap while DC fast chargers cost several times more. Everything is computed locally and deterministically, so it is instant and private. Ideal for EV apps, route and trip planners, fleet and charging-station tools, charge-cost calculators and dashboards. Pure local computation — no key, no third-party service, instant. Estimates — real DC charging tapers above 80 % and cold weather cuts range. 3 compute endpoints. For battery runtime use a battery API; for generic energy cost use an energy-cost API.

Uptime

100.0%

Latency

88ms

Subs

3,219

Multirotor (drone) flight maths as an API, computed locally and deterministically — the thrust, efficiency and hover numbers an FPV builder or UAV designer dials a quadcopter in with. The thrust-weight endpoint gives the thrust-to-weight ratio, total motor thrust ÷ all-up weight: aim for at least 2:1 so the craft has authority to hold position and fight wind, with freestyle wanting 3–5:1 and heavy-lift living near 1.5:1 — four 800-gram motors on a 1,200-gram quad is a punchy 2.67:1. The disk-loading endpoint gives the rotor disk loading, weight ÷ total prop disk area, where lower is more efficient: big slow props move more air for less power, which is why endurance and cinematic rigs run large props at low disk loading. The hover-throttle endpoint gives the hover throttle, all-up weight ÷ total thrust — a good build hovers near 40–50 % leaving headroom for manoeuvres, while hovering above ~60 % means it is overweight, sluggish and runs hot. Everything is computed locally and deterministically, so it is instant and private. Ideal for FPV and drone-build apps, UAV-design and motor-selection tools, hobbyist calculators, and maker sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — bench-test motors at your voltage and prop. For battery runtime use a battery API.

Uptime

100.0%

Latency

71ms

Subs

4,319

Pressure-washer maths as an API, computed locally and deterministically — the cleaning-power, nozzle and water numbers a buyer or pro sizes and runs a machine by. The cleaning-units endpoint gives the cleaning power, PSI × GPM, with a duty class — both matter because pressure breaks the dirt loose and flow flushes it away, so a 3,000 PSI / 2.5 GPM machine (7,500 cleaning units) cleans far faster than the same pressure at 1.5 GPM. The nozzle endpoint gives the flow at a different pressure (a fixed nozzle flows with the square root of pressure) and the nozzle reaction force you feel, ≈ 0.0526 × GPM × √PSI in pounds — a few pounds on a consumer unit, enough on a big machine to need two hands. The water-usage endpoint gives the water used over a run, flow × time, in gallons and litres with an optional cost — a pressure washer actually uses far less water than a garden hose for the same cleaning. Everything is computed locally and deterministically, so it is instant and private. Ideal for pressure-washer shops and rental apps, cleaning-contractor and buying-guide tools, equipment calculators, and DIY sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — surface and detergent matter as much as the numbers.

Uptime

100.0%

Latency

75ms

Subs

4,427

Solar-thermal (solar hot water) maths as an API, computed locally and deterministically — the collector, sizing and storage numbers a solar installer or homeowner designs a hot-water system with. The output endpoint gives the useful daily heat a collector makes: area × the daily solar energy on it × the collector efficiency (flat-plate ~40–60 %, evacuated tubes higher), so a 40 ft² collector under 1,800 BTU/ft²/day at 50 % delivers about 36,000 BTU (10.5 kWh) — a family's hot water on a good day. The area endpoint sizes the collector for a demand: area = (daily gallons × 8.34 × the temperature rise) ÷ (irradiance × efficiency), so 60 gallons raised 70 °F needs about 39 ft² — sized for an average day with a backup heater, since a 60–80 % solar fraction is the economic sweet spot. The tank endpoint sizes solar storage at about 1.5 gallons per square foot of collector, big enough to bank a sunny afternoon without stalling the collector. Everything is computed locally and deterministically, so it is instant and private. Ideal for solar-installer and renewable-energy apps, hot-water-system design tools, home-energy calculators, and sustainability sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For the local solar resource use a solar-irradiance API; for pool heating use a pool API.

Uptime

100.0%

Latency

76ms

Subs

3,962

Pipe-insulation heat-loss maths as an API, computed locally and deterministically — the radial heat loss, thickness and energy-cost numbers a mechanical engineer or energy auditor sizes lagging with. The heat-loss endpoint gives the loss per linear foot through cylindrical insulation, Q/L = 2π·(k/12)·ΔT ÷ ln(r2/r1), where k is the insulation conductivity (BTU·in/hr·ft²·°F, ~0.25 for fibreglass), r1 the pipe radius and r2 the outer radius — a 2-inch line at 300 °F with one inch of fibreglass loses about 43 BTU/hr per foot, and because the relationship is logarithmic, doubling the thickness does not halve the loss. The thickness endpoint inverts it for a target loss: ln(r2/r1) = 2π·(k/12)·ΔT ÷ target, then thickness = r2 − r1, showing the economic-thickness point beyond which more material rarely pays. The annual-cost endpoint turns loss per foot into the yearly heat lost and fuel cost over a run of pipe, the number that justifies the lagging. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical-design and energy-audit apps, insulation-contractor and process-piping tools, building-services calculators, and engineering aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Ignores the outer air film (real loss slightly lower). For flat walls and roofs use a U-value API.

Uptime

100.0%

Latency

71ms

Subs

4,139

CNC surface-finishing maths as an API, computed locally and deterministically — the scallop, stepover and pass numbers a CNC machinist dials in for a smooth finish. The scallop endpoint gives the cusp height a ball-nose tool leaves between passes, h = R − √(R² − (stepover/2)²), so a half-inch ball at a 0.05-inch stepover leaves about a 1.25-thou ridge — tighter stepover, smaller cusp, far more passes. The stepover endpoint inverts it: the stepover for a target scallop height, 2·√(R² − (R−h)²), reported also as a percent of tool diameter (fine finishing runs ~4–10 %) so it carries across jobs — and a bigger finishing ball reaches the same finish at a wider, faster stepover. The passes endpoint turns a surface into work: passes = width ÷ stepover rounded up plus one, the total cutting travel, and the cutting time at a given feed rate — surfacing a 4×6-inch area at a 0.05-inch stepover is 81 passes and 486 inches of travel, under five minutes at 100 ipm. Everything is computed locally and deterministically, so it is instant and private. Ideal for CNC and CAM apps, machinist and toolpath calculators, maker and job-shop tools, and engineering aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For cutting speed, feed and rpm use a machining API.

Uptime

100.0%

Latency

75ms

Subs

4,693

Roller-chain drive maths as an API, computed locally and deterministically — the chain-length, sprocket and speed numbers a machine designer or millwright lays out a drive with. The chain-length endpoint gives the chain in pitches from the two sprocket tooth counts, the chain pitch and the centre distance: L = 2·C + (N1+N2)/2 + ((N2−N1)/2π)² ÷ C (C in pitches), rounded UP to an even number so the chain closes without an offset link — a 17- and 34-tooth pair at 15-inch centres on #40 (half-inch) chain comes to 86 pitches, 43 inches. The sprocket endpoint gives the pitch diameter, pitch ÷ sin(180°/teeth), and the outside diameter — a 17-tooth #40 sprocket has a 2.72-inch pitch circle. The speed endpoint gives the chain's linear speed, pitch × teeth × rpm ÷ 12, so a 17-tooth #40 sprocket at 100 rpm runs the chain at about 71 ft/min. Everything is computed locally and deterministically, so it is instant and private. Ideal for machine-design and drivetrain apps, conveyor and equipment-build tools, maker and CAD calculators, and engineering aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. For gear ratios use a gear-ratio API; for belts use a pulley API.

Uptime

100.0%

Latency

76ms

Subs

4,640

Water-well maths as an API, computed locally and deterministically — the casing, yield and pump-setting numbers a well driller, pump installer or rural homeowner works to. The casing-volume endpoint gives the standing water in a well: gallons per foot = π/4 · diameter² × 12 ÷ 231 (about 1.47 gal/ft for a 6-inch casing, 0.65 for a 4-inch) times the water column, so 100 feet of water in a 6-inch casing holds about 147 gallons — the figure you need to purge a few well volumes before sampling or to dose shock-chlorination. The specific-capacity endpoint turns a drawdown test into how freely the well gives up water: specific capacity = pumping rate ÷ drawdown (gpm per foot), and the projected yield ≈ that times the available drawdown — 15 GPM at 20 feet of drawdown is 0.75 gpm/ft and roughly 45 GPM at 60 feet. The pump-setting endpoint gives the depth to hang the pump: static water level + drawdown + submergence (typically 10–20 feet), so it never air-locks as the level draws down, with a check against the well depth. Everything is computed locally and deterministically, so it is instant and private. Ideal for well-drilling and pump-installer apps, rural-water and homeowner tools, hydrogeology calculators, and trade aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — verify with a real drawdown test. For pump power/head use a pump API; for well chlorination use a pool-chemistry API.

Uptime

100.0%

Latency

70ms

Subs

4,218

Screw-conveyor and grain-auger maths as an API, computed locally and deterministically — the capacity, speed and throughput numbers a farmer, millwright or material-handling engineer sizes an auger with. The capacity endpoint gives the volumetric throughput from the screw geometry: the annular flight volume per turn ((π/4)(diameter² − shaft²) × pitch) × rpm × 60 × the trough loading, so a 9-inch full-pitch screw on a 2.5-inch shaft at 40 rpm and 45 % loading moves about 330 cubic feet — 265 bushels — an hour. The speed endpoint inverts it, the rpm needed for a target capacity, so you don't overspeed a small auger and grind the grain. The bushels endpoint converts a volumetric rate to bushels and tons per hour (1 bushel = 1.2445 ft³, tons = bushels × test weight ÷ 2000), so 330 ft³/hr of 56-lb corn is 265 bushels or 7.4 tons an hour — the number you match to the dryer or the truck. Everything is computed locally and deterministically, so it is instant and private. Ideal for grain-handling and ag-equipment apps, material-handling and conveyor-design tools, farm-build calculators, and engineering aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — incline and material change real throughput. For belt conveyors use a conveyor API.

Uptime

100.0%

Latency

75ms

Subs

3,034

Radiant-floor and hydronic heating maths as an API, computed locally and deterministically — the output, tubing and flow numbers an installer or DIYer designs a warm floor with. The output endpoint gives the heat a warm floor puts out: about 2 BTU/hr per square foot for every °F the floor surface is above the room, so an 85 °F floor in a 70 °F room delivers roughly 30 BTU/hr/ft² — about 9,000 BTU/hr over 300 ft², the comfort ceiling since the floor is held at ~85 °F. The tubing endpoint gives the tube and loops for an area at a spacing: field tubing = area × 12 ÷ spacing, so 300 ft² at 9-inch spacing needs 400 feet of tube, split into loops kept under ~300 feet (two 200-foot loops) so the pump can push them. The flow endpoint gives the loop flow rate for a heat load, GPM = load ÷ (500 × ΔT) where 500 is water's constant and ΔT is the supply-to-return drop — 9,000 BTU/hr at a 20 °F ΔT wants 0.9 GPM. Everything is computed locally and deterministically, so it is instant and private. Ideal for radiant-heating and plumbing apps, hydronic-design and PEX-layout tools, HVAC contractor calculators, and DIY-build sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — verify with a full heat-loss calc. For building load use an HVAC API; for pipe velocity use a flow-rate API.

Uptime

100.0%

Latency

81ms

Subs

3,688

Ladder-safety maths as an API, computed locally and deterministically — the angle, reach and load numbers that keep a ladder from sliding out or buckling. The angle endpoint applies the 4:1 rule: the base goes out one foot for every four feet of working length, which lands the ladder at about 75.5° — a 24-foot ladder sits 6 feet from the wall and reaches roughly 23 feet up, steep enough not to tip back and shallow enough not to slide. The extension endpoint gives the usable length and reach of a two-section extension ladder, which loses the overlap the sections share (3 feet up to 36, 4 to 48, 5 beyond), and the working height at the safe angle — remembering the ladder must extend 3 feet above a roof edge you step onto. The duty-rating endpoint turns a total load — your weight plus tools and materials, not just bodyweight — into the right duty class, from Type III household (200 lb) through I industrial (250) to IAA professional (375). Everything is computed locally and deterministically, so it is instant and private. Ideal for construction-safety and trades apps, jobsite and rental tools, OSHA training aids, and home-improvement sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Educational — always follow the manufacturer's labels and OSHA/ANSI rules.

Uptime

100.0%

Latency

74ms

Subs

3,044

Guitar and luthier maths as an API, computed locally and deterministically — the string-tension and fret numbers a player, builder or tech sets an instrument up with. The string-tension endpoint gives the tension a string pulls at pitch from the physics, tension = unit weight × (2 × scale length × frequency)² ÷ 386.4, where the unit weight (lb/in) comes from the string maker's chart — a .010 plain-steel high E on a 25.5-inch scale tuned to 329.6 Hz pulls about 16 lb. The fret-position endpoint gives the distance from the nut to any fret in equal temperament, scale × (1 − 2^(−fret/12)), so the 12th fret sits exactly halfway and the first fret of a 25.5-inch scale is 1.43 inches down — the maths behind every fretboard slot. The set-tension endpoint sums a whole string set into the total load on the neck (a typical six-string runs ~95–120 lb), the number that decides whether a gauge or tuning change needs a truss-rod re-setup. Everything is computed locally and deterministically, so it is instant and private. Ideal for luthier and guitar-tech apps, string-tension and fret-slotting calculators, setup and re-string tools, and music-gear sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Get unit weights from the string maker's chart. For note↔frequency conversion use a music-theory API.

Uptime

100.0%

Latency

73ms

Subs

3,887

Compressed-air maths as an API, computed locally and deterministically — the receiver, pump-up and SCFM numbers a pneumatics tech or shop owner sizes a system with. The receiver-size endpoint gives the tank you need to ride out a demand burst: volume = demand (free-air CFM) × minutes × 14.7 ÷ the usable pressure window (max − min) — pulling 20 CFM for a minute over a 175-to-100 psi window wants about a 30-gallon receiver, the buffer that lets the pump catch up. The pumpup endpoint gives the time to raise a receiver from one pressure to another: volume × pressure rise ÷ (14.7 × compressor CFM), so a 60-gallon tank from 100 to 175 psi on a 15 CFM compressor takes about 2.7 minutes. The scfm endpoint corrects actual CFM to standard CFM for the inlet conditions — SCFM = ACFM × (inlet pressure ÷ 14.696) × (528 ÷ inlet temperature in Rankine) — so a compressor at 5,000 feet delivers about 17 % fewer SCFM than at sea level, the reason you size tools on SCFM, not the nameplate. Everything is computed locally and deterministically, so it is instant and private. Ideal for pneumatics and shop-air apps, compressor-sizing and tool-demand tools, industrial-air calculators, and trade aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — duty cycle and the pump curve shift real numbers.

Uptime

100.0%

Latency

92ms

Subs

3,866

Tire maths as an API, computed locally and deterministically — the size, pressure and speedometer numbers a driver, fitter or fleet manager works out before fitting a tyre. The size endpoint turns a P-metric spec into the real dimensions: overall diameter = rim + 2 × the sidewall (section width × aspect ratio), so a 225/45R17 stands about 25 inches tall, rolls a 78-inch circumference and turns roughly 808 times a mile — the numbers behind fitment, gearing and clearance. The pressure endpoint gives the hot pressure from a cold pressure and the temperature change, because pressure tracks absolute temperature (P2/P1 = T2/T1), about +1 psi per 10 °F — so 32 psi set cold at 70 °F reads ~34.6 after warming to 100 °F, and drops on a cold morning, which is what trips the warning light. The speedo-error endpoint gives the speedometer error and true speed from a tyre-size change: a taller tyre makes the speedo read low, so actual speed = indicated × new diameter ÷ old — go up 4 % and 60 on the dial is really 62.5. Everything is computed locally and deterministically, so it is instant and private. Ideal for tyre-shop and fitment apps, fleet and 4x4 build tools, speedo-recalibration calculators, and automotive sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — always set pressure cold to the placard.

Uptime

100.0%

Latency

81ms

Subs

3,314

Boat-propeller maths as an API, computed locally and deterministically — the slip, RPM and pitch numbers that decide whether a boat hits its numbers or labours. The slip endpoint gives propeller slip from the pitch, the prop RPM and the actual boat speed: theoretical speed = pitch × prop RPM ÷ 1215, and slip = (theoretical − actual) ÷ theoretical — a 19-inch prop at 2000 RPM should make 31 knots in theory, so a real 26.6 knots is about 15 % slip, normal for a clean planing boat. The prop-rpm endpoint gives the propeller RPM from the engine RPM and the gear (reduction) ratio — a 2:1 gearbox spins the prop at half engine speed — and, with a pitch, the theoretical no-slip speed at that RPM. The pitch endpoint gives the pitch needed to reach a target speed at a prop RPM and expected slip, pitch = target × 1215 ÷ (prop RPM × (1 − slip)), so you can prop the boat to let the engine reach the top of its wide-open-throttle range instead of lugging. Everything is computed locally and deterministically, so it is instant and private. Ideal for boating and marine apps, repower and prop-shop tools, performance calculators, and seamanship study aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — hull, load and bottom condition shift real slip.

Uptime

100.0%

Latency

73ms

Subs

3,999

Boat-anchoring maths as an API, computed locally and deterministically — the scope, swing and load numbers a sailor or boater sets the hook by. The scope endpoint gives the rode to let out: scope = rode ÷ the vertical from the seabed to the bow roller (water depth + bow height), measured at high tide, so anchoring in 20 feet with a 4-foot bow at the classic 7:1 means paying out 168 feet of rode — let out more in a blow, and never less than 5:1 on all chain. The swing endpoint gives the circle the boat swings on: radius = the horizontal reach of the rode (√(rode² − vertical²)) plus the boat length, so that 168-foot rode on a 30-foot boat sweeps a 196-foot radius — the room you must leave every other boat, which swings too. The load endpoint gives the wind load the ground tackle has to hold, 0.00256 × drag coefficient × frontal windage area × wind speed², which quadruples every time the wind doubles — 50 square feet of windage takes 138 lb at 30 mph but 553 lb at 60. Everything is computed locally and deterministically, so it is instant and private. Ideal for sailing and boating apps, anchoring and cruising tools, ground-tackle sizing calculators, and seamanship study aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — add current, waves and a safety margin.

Uptime

100.0%

Latency

76ms

Subs

4,461

Vehicle-suspension maths as an API, computed locally and deterministically — the spring and frequency numbers a racer, tuner or chassis engineer sets a car up with. The wheel-rate endpoint converts a spring rate to the rate the wheel actually feels: wheel rate = spring rate × motion ratio², where the motion ratio is the spring's travel per unit of wheel travel — a 200 lb/in spring at a 0.7 motion ratio gives a 98 lb/in wheel rate, because the spring's leverage softens it. The frequency endpoint gives the ride (natural) frequency at a corner, f = (1/2π)·√(wheel rate × g ÷ corner sprung weight), the number that really sets the ride: luxury cars run about 0.5–1.2 Hz, sporty street 1.2–1.7, race cars 2 Hz and up. The spring-rate endpoint inverts it — the spring rate needed to hit a target frequency for a corner weight and motion ratio — so you can pick the frequency for the car's job and get the spring straight out. Everything is computed locally and deterministically, so it is instant and private. Ideal for motorsport and tuning apps, chassis-setup and corner-balancing tools, suspension-design calculators, and engineering study aids. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. Estimates — real ride also depends on damping and tyres.

Uptime

100.0%

Latency

73ms

Subs

3,650