API marketplace

HVAC air-side heat maths as an API, computed locally and deterministically with the classic standard-air factors — the sensible, latent and airflow numbers a mechanical engineer or HVAC technician sizes ducts and equipment with. The sensible endpoint gives the sensible heat an airflow carries to change temperature: Qs = 1.08 × CFM × ΔT (dry-bulb difference), where the 1.08 bundles standard-air density and specific heat — 2,000 CFM across a 20 °F difference is 43,200 BTU/hr, 3.6 tons — with the result in BTU/hr, tons and kW. The latent endpoint gives the latent (moisture) heat: Ql = 0.68 × CFM × ΔW, where ΔW is the humidity-ratio difference in grains of water per pound of dry air, the dehumidification part of a cooling load that runs high in humid climates and from people and cooking, and why air conditioners are sized on total, not just temperature. The airflow endpoint inverts the sensible relation: CFM = sensible load ÷ (1.08 × ΔT), the supply air needed at a chosen supply-to-room temperature difference (comfort cooling runs ~18–22 °F below room), the number that sets fan and duct size — sanity-checked against ~400 CFM per ton. Everything is computed locally and deterministically, so it is instant and private. Ideal for HVAC-design and load-calc tools, mechanical-estimating and commissioning utilities, and building-engineering apps. Pure local computation — no key, no third-party service, instant. Standard-air factors — adjust for altitude. 3 compute endpoints. For room rule-of-thumb sizing use an HVAC API; for moist-air properties a psychrometric API; for duct sizing a ductwork API.

Uptime

100.0%

Latency

79ms

Subs

4,206

Earthwork volume maths as an API, computed locally and deterministically — the cut/fill-quantity and soil-state numbers a civil engineer, estimator or grading contractor runs for a road, trench or site. The average-end-area endpoint gives the volume between two cross-sections = the mean of the two end areas × the distance between them, ÷ 27 for cubic yards — the everyday earthwork-quantity method you sum section by section down an alignment (a 100 ft²/150 ft² pair 100 ft apart is about 463 cy). The prismoidal endpoint gives the more accurate Simpson volume = length ÷ 6 × (A₁ + 4·A_mid + A₂) using the true middle-section area, preferred for payment quantities where the average-end-area over-estimate would matter. The soil-state endpoint converts between the three states earth passes through: loose = bank × (1 + swell %) (excavating loosens it, ~25 %, so you haul more cubic yards than you cut) and compacted = bank × (1 − shrinkage %) (placing and compacting shrinks it, ~10 %) — which is why a balanced cut-and-fill needs more bank cut than the compacted fill, with the load factor for truck sizing. Everything is computed locally and deterministically, so it is instant and private. Ideal for grading and site-work estimating, surveying and civil-design tools, and earthmoving calculators. Pure local computation — no key, no third-party service, instant. US units (ft², ft, cy). 3 compute endpoints. For tank/storage volumes use a tank API; for concrete mix a concrete API.

Uptime

100.0%

Latency

75ms

Subs

3,184

Vertical (parabolic) road-curve geometry as an API, computed locally and deterministically — the K-value, profile-elevation and design-length numbers a highway engineer or surveyor lays a crest or sag curve out with. The geometry endpoint takes the incoming and outgoing grades and the length and returns the algebraic grade difference A = g2 − g1 (negative is a crest, positive a sag), the K value = length ÷ |A| (the headline number on every design chart), the high or low point offset −g1·L/A from the PVC, and — given the PVI station and elevation — the PVC and PVT coordinates and the turning-point station and elevation. The elevation endpoint evaluates the parabola at any station: elevation = PVC elevation + (g1/100)·x + (A/(200·L))·x², with the instantaneous grade g1 + (A/L)·x that sweeps smoothly from g1 to g2 — the smooth change of grade that makes the ride and sight line comfortable. The min-length endpoint gives the AASHTO minimum length for stopping sight distance: crest L = A·S² ÷ 2158 and sag (headlight) L = A·S² ÷ (400 + 3.5·S), with the controlling K, because a crest hides the road over the hump and a sag limits the headlight reach at night. Everything is computed locally and deterministically, so it is instant and private. Ideal for highway- and rail-design tools, surveying and civil-engineering utilities, and CAD/GIS profile work. Pure local computation — no key, no third-party service, instant. US units (ft, %, mph). 3 compute endpoints. For horizontal curves use a horizontal-curve API; for slope conversion a slope API.

Uptime

100.0%

Latency

74ms

Subs

4,162

Horizontal road-curve geometry as an API, computed locally and deterministically — the curve-element, stationing and design-radius numbers a highway engineer, surveyor or civil-design tool lays out a road or railway curve with. The geometry endpoint takes the radius and the intersection (deflection) angle and returns the full simple circular curve: the tangent T = R·tan(Δ/2), the curve length L = R·Δ in radians, the long chord LC = 2R·sin(Δ/2), the middle ordinate M = R(1−cos(Δ/2)) and the external distance E = R(sec(Δ/2)−1), plus the degree of curve (arc definition) = 5729.578 ÷ R, the US shorthand for sharpness. The stations endpoint lays the curve out from the PI: the PC (point of curvature) = PI − tangent and the PT (point of tangency) = PC + curve length — and it reminds you the PT is reached along the arc, not by adding the tangent again. The min-radius endpoint gives the minimum radius for a design speed (AASHTO) R = V² ÷ (15·(e + f)), where e is the superelevation and f the side-friction factor, the banking-plus-grip that holds a vehicle in the turn. Everything is computed locally and deterministically, so it is instant and private. Ideal for highway- and rail-design tools, surveying and civil-engineering utilities, and CAD/GIS road layout. Pure local computation — no key, no third-party service, instant. US units (ft, mph). 3 compute endpoints. For slope and grade use a slope API; for open-channel drainage a Manning API.

Uptime

100.0%

Latency

73ms

Subs

4,627

Telescope optics maths as an API, computed locally and deterministically — the magnification, exit-pupil and resolving-power numbers an amateur astronomer or stargazing-app developer picks gear and eyepieces with. The magnification endpoint gives magnification = the telescope's focal length ÷ the eyepiece focal length (a 1000 mm scope with a 10 mm eyepiece is 100×), the focal ratio, and — from the aperture — the useful range from about the aperture in mm ÷ 7 (lowest useful, a 7 mm exit pupil) up to roughly 2× the aperture in mm, beyond which the image only dims and blurs; pass an eyepiece apparent field and it returns the true field of view. The exit-pupil endpoint gives aperture ÷ magnification, the width of the light beam leaving the eyepiece — a big 4–7 mm exit pupil for bright wide views of nebulae, a small 0.5–2 mm for the Moon and planets at high power. The resolution endpoint gives the Dawes limit ≈ 116 ÷ aperture(mm) and the slightly stricter Rayleigh limit ≈ 138 ÷ aperture in arcseconds, plus the limiting magnitude ≈ 2.7 + 5·log₁₀(aperture mm) — bigger glass splits finer doubles and reaches fainter stars, though seeing usually caps real resolution near 1 arcsecond. Everything is computed locally and deterministically, so it is instant and private. Ideal for astronomy and stargazing apps, telescope-shop and eyepiece-calculator tools, and observing-planner utilities. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For camera/thin-lens imaging use a lens API; for stellar magnitudes a star-magnitude API.

Uptime

100.0%

Latency

81ms

Subs

3,088

Powerlifting strength-score maths as an API, computed locally and deterministically — the Wilks, DOTS and IPF GL numbers a meet, gym or training app uses to compare lifters across bodyweights and sexes. The wilks endpoint gives the classic Wilks coefficient (1996) and score: total × 500 ÷ a fifth-order polynomial in bodyweight, with separate male and female curves — long the federation standard for "best lifter", a 100 kg man totalling 600 kg scores about 365. The dots endpoint gives the modern DOTS score (2019), the same total × 500 ÷ polynomial idea but fitted to updated data with a fourth-order curve that is fairer across the weight classes and not skewed to the middleweights, now the default in most raw meet software. The ipf-gl endpoint gives the International Powerlifting Federation's current GL Points (2020): 100 × total ÷ (A − B·e^(−C·bodyweight)), with separate constants for sex and for raw (classic) versus equipped lifting, the official metric at IPF championships. Everything is computed locally and deterministically, so it is instant and private. Ideal for meet-management and scoring software, gym leaderboards and training-log apps, and strength-sport tools. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For one-rep-max estimation and plate loading use a strength-training API.

Uptime

100.0%

Latency

80ms

Subs

4,799

Cable-tray fill engineering maths as an API, computed locally and deterministically from NEC Article 392 — the allowable-fill, single-layer and tray-width numbers an electrician, estimator or designer runs for a tray run. The fill endpoint applies NEC 392.22(A)(1) Column 1 for multiconductor power and lighting cables no larger than 4/0 in a ladder or ventilated-bottom tray: the total cable cross-sectional area is capped at the tray width × 7/6, so a 12-inch tray allows 14 in² — sum every cable's csa, get the percentage fill and whether it is within code, with the spare area left. The large-cable endpoint covers cables 4/0 and larger, which must lie in a single layer with the sum of their diameters not exceeding the tray width — no stacking — so it returns the spare width and the code check. The min-width endpoint inverts the rule to size the tray: minimum width = cable area × 6/7, rounded up to a standard 6/9/12/18/24/30/36-inch width, leaving room for spare capacity and future cables. Everything is computed locally and deterministically, so it is instant and private. Ideal for electrical-design and estimating tools, industrial and OSP utilities, and code-check calculators. Pure local computation — no key, no third-party service, instant. Ladder/ventilated trays; solid-bottom and mixed fills use the other NEC columns, and ampacity must be derated for fill. 3 compute endpoints. For conduit and box fill use a conduit API.

Uptime

100.0%

Latency

75ms

Subs

3,364

Off-grid solar system-sizing maths as an API, computed locally and deterministically — the battery-bank, solar-array and charge-controller numbers an RV, cabin, boat or off-grid homeowner sizes a system with. The battery-bank endpoint gives the storage you need = (daily load × days of autonomy) ÷ (depth of discharge × round-trip efficiency), then ÷ the system voltage for amp-hours: the autonomy carries you through cloudy days and the depth-of-discharge limit protects the cells (lead-acid ~50 %, lithium 80–100 %, which is why lithium banks run smaller), so a 2 kWh/day load at 12 V with 2 days autonomy, 50 % DoD and 85 % efficiency needs about 785 Ah. The array endpoint gives the panels = daily energy ÷ (peak sun hours × system efficiency), where peak sun hours is the day's irradiance as equivalent full-sun hours (~3–6 by place and season) and the efficiency rolls up controller, wiring, heat and dust losses — about 670 W for that load at 4 sun hours and 75 %. The charge-controller endpoint sizes the controller = array watts ÷ battery voltage × a 1.25 safety factor, so a 700 W array on a 12 V bank wants roughly an 80 A controller. Everything is computed locally and deterministically, so it is instant and private. Ideal for solar-installer and DIY tools, RV/marine/cabin power planners, and renewable-energy calculators. Pure local computation — no key, no third-party service, instant. Size for the worst month. 3 compute endpoints. For solar irradiance and sun hours use a solar API; for battery runtime under load a battery API.

Uptime

100.0%

Latency

71ms

Subs

4,821

Aircraft fuel-planning maths as an API, computed locally and deterministically — the endurance, range and fuel-required numbers a pilot, dispatcher or flight-sim developer plans a flight with, all honouring a reserve. The endurance endpoint gives how long you can fly = usable fuel ÷ burn rate, holding back a reserve (30 min day / 45 min night VFR, 45 min IFR is typical), so the usable endurance is the time you can actually plan to rather than the tanks-dry figure — 50 gallons at 10 gph is 5:00 total but 4:15 usable on a 45-minute reserve. The range endpoint turns that into distance = usable endurance × ground speed, so it lives or dies on the wind: a headwind cuts the ground speed and the range while burning the same fuel per hour, which is why you plan on the forecast ground speed, not the true airspeed. The fuel-required endpoint sizes the load for a leg = trip time × burn plus the reserve — 300 nm at 120 kt and 10 gph needs 25 gallons of trip fuel plus 7.5 reserve, 32.5 total — to which a real flight adds taxi and climb allowances. Everything is computed locally and deterministically, so it is instant and private. Ideal for flight-planning and EFB apps, dispatch and flight-school tools, flight-simulator utilities, and general-aviation calculators. Pure local computation — no key, no third-party service, instant. Add taxi/climb and a personal margin; confirm against tank capacity and weight-and-balance. 3 compute endpoints. For glide range use a glide-ratio API; for density altitude a density-altitude API.

Uptime

100.0%

Latency

77ms

Subs

3,298

Aircraft glide-performance maths as an API, computed locally and deterministically — the glide-distance, glide-ratio and reachability numbers a pilot, flight-instructor or flight-sim developer works an engine-out or soaring problem with. The glide-distance endpoint gives the still-air distance you can cover = height above the ground × the glide ratio (L/D): from 5,000 ft at a 9:1 ratio you reach about 45,000 ft, ~7.4 nm, with the answer in feet, nautical miles and kilometres. The glide-ratio endpoint reads the slope straight off the polar — glide ratio = forward speed ÷ sink rate (1 knot ≈ 101.27 ft/min), so 60 kt at a 600 ft/min sink is about 10:1, a 5.6° glide path — and gliders reach 40–60:1, a light single ~9:1, an airliner ~17:1. The reach endpoint answers the practical question: the height needed to reach a field = distance ÷ glide ratio, the arrival height is what is left, and it only counts as making it if that clears a safety reserve (default 1,000 ft) for the circuit and approach. Everything is computed locally and deterministically, so it is instant and private. Ideal for flight-planning and EFB apps, gliding and soaring tools, flight-simulator and training utilities, and aviation-safety calculators. Pure local computation — no key, no third-party service, instant. Still-air estimates — adjust for wind, configuration and a margin. 3 compute endpoints. For density altitude use a density-altitude API; for runway wind components a crosswind API.

Uptime

100.0%

Latency

76ms

Subs

4,442

Turbocharger and boost engineering maths as an API, computed locally and deterministically — the pressure-ratio, charge-air and airflow numbers a tuner, engine builder or motorsport engineer sizes forced induction with. The pressure-ratio endpoint gives the compressor pressure ratio = absolute manifold pressure ÷ ambient = (atmospheric + boost) ÷ atmospheric, so 10 psi at sea level is a 1.68 ratio — the x-axis of every compressor map, which climbs at altitude where ambient pressure is lower. The charge-air endpoint shows why an intercooler matters: compressing air heats it (T₂ = T₁ × (1 + (PR^0.2857 − 1)/efficiency)), and hot air is less dense, so the real gain is the charge density ratio = pressure ratio × (T₁/T_charge), not the pressure ratio alone — 10 psi at 70 % compressor efficiency makes ~93 °C and a 1.37 density ratio with no intercooler, rising toward 1.6 once an intercooler claws back the heat, and the estimated power gain tracks the density. The airflow endpoint gives the engine mass airflow ≈ displacement × (rpm/2) × volumetric efficiency × charge density, in lb/min — the y-axis of the compressor map you plot against the pressure ratio to land in the efficient island and avoid surge or choke. Everything is computed locally and deterministically, so it is instant and private. Ideal for engine-tuning and turbo-sizing tools, dyno and data-logging apps, and motorsport calculators. Pure local computation — no key, no third-party service, instant. Sizing estimates — verify on a dyno. 3 compute endpoints. For engine displacement and compression use an engine API; for shop compressed air a compressor API.

Uptime

100.0%

Latency

69ms

Subs

3,936

Electric-motor electrical maths as an API, computed locally and deterministically — the full-load-current, NEC-sizing and starting-current numbers an electrician, panel designer or estimator runs for every motor circuit. The full-load-amps endpoint gives the motor current from its power, voltage and phase: FLA = (output ÷ efficiency) ÷ (√3 × volts × power factor) for three-phase (drop the √3 for single-phase) — a 10 hp, 460 V, three-phase motor at 90 % efficiency and 0.85 power factor draws about 12.2 A — and it also returns the input kW and kVA. The sizing endpoint applies NEC Article 430 from the full-load current: branch-circuit conductors at 125 %, overload protection at 115–125 % by service factor, and branch-circuit short-circuit/ground-fault protection up to 250 % for an inverse-time breaker or 175 % for a time-delay fuse — the larger protection lets the inrush pass while the overload guards the windings. The starting endpoint gives the locked-rotor (inrush) current, about six times full-load for an across-the-line start, the figure that sets the voltage dip and why soft starters and VFDs exist. Everything is computed locally and deterministically, so it is instant and private. Ideal for electrical-design and estimating tools, panel-builder and field utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Calculated values — use the NEC FLC tables for code work. 3 compute endpoints. For general three-phase power use a three-phase API; for conduit fill a conduit API.

Uptime

100.0%

Latency

71ms

Subs

4,688

Photographic exposure maths as an API, computed locally and deterministically — the exposure-value, equivalent-exposure and Sunny-16 numbers a photographer, camera-app developer or educator works the exposure triangle with. The exposure-value endpoint gives EV = log₂(aperture² ÷ shutter) and the ISO-100-normalised EV100 (subtracting log₂(ISO/100)) — every one-EV step is a stop, a doubling or halving of light — so bright sun reads about EV 15 and a typical interior EV 6–8, and equal-EV settings give the same exposure. The equivalent endpoint applies the reciprocity at the heart of the triangle: exposure ∝ shutter × ISO ÷ f-number², so when you close the aperture or drop the ISO it returns the new shutter that keeps the brightness constant — going from f/2.8 to f/5.6 needs four times the shutter time. The sunny16 endpoint gives the classic meterless rule: in bright sun shoot f/16 at about 1/ISO (1/125 s at ISO 100), opening up in stops for softer light — slight overcast f/11, overcast f/8, heavy overcast f/5.6, open shade f/4, and f/22 on snow or sand — solving the shutter for your chosen ISO and aperture. Everything is computed locally and deterministically, so it is instant and private. Ideal for camera and photography apps, exposure-calculator and teaching tools, and metering and automation utilities. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For depth of field and hyperfocal distance use a photography (optics) API.

Uptime

100.0%

Latency

76ms

Subs

3,802

Fiber-optic link-budget engineering maths as an API, computed locally and deterministically — the power-budget, loss and reach numbers a network or fibre engineer designs an optical link with. The power-budget endpoint gives the optical power budget = transmit power − receiver sensitivity (in dBm), the total loss the link can tolerate: a 0 dBm transmitter into a −23 dBm receiver gives a 23 dB budget, with the powers also shown in milliwatts. The loss endpoint adds up the real link loss from the fibre attenuation × length plus the connector and splice losses — single-mode fibre runs about 0.35 dB/km at 1310 nm and 0.20 dB/km at 1550 nm, each mated connector ~0.5 dB and each fusion splice ~0.1 dB — so 10 km of fibre with two connectors is 4.5 dB. The reach endpoint gives the maximum distance = (power budget − fixed losses − system margin) ÷ the fibre attenuation, reserving a margin (typically 3 dB) for ageing, bends and future repair splices so the link still works years on. Everything is computed locally and deterministically, so it is instant and private. Ideal for FTTx and data-centre link planning, network-engineering and OSP tools, fibre-survey and design utilities, and telecom calculators. Pure local computation — no key, no third-party service, instant. Loss-limited model — at high bit rates dispersion can cap distance first. 3 compute endpoints. For fibre numerical aperture and photonics use a fiber API; for RF line-of-sight a Fresnel-zone API.

Uptime

100.0%

Latency

76ms

Subs

4,798

Seawater oceanography maths as an API, computed locally and deterministically from the standard equations — the density, freezing-point and chlorinity numbers an oceanographer, marine scientist or aquarist works with. The density endpoint gives the seawater density and σt from salinity and temperature using the full UNESCO EOS-80 one-atmosphere equation of state — it reproduces the official check value of 1027.675 kg/m³ at 35 PSU and 5 °C exactly — around 1,025 kg/m³, rising with salinity and falling with temperature, the two drivers of the ocean's density-driven circulation where cold salty water sinks. The freezing-point endpoint gives the freezing point from salinity (Millero): about −1.9 °C at the ocean's typical 35 ppt, and because salt also pushes the temperature of maximum density below freezing, seawater keeps overturning and cooling all the way down instead of stratifying like a freshwater lake — why the open ocean rarely freezes outside the polar seas. The chlorinity endpoint converts between salinity and chlorinity through the Knudsen relation S = 1.80655 × Cl, the classic titration measure that the constant major-ion proportions of seawater make reliable. Everything is computed locally and deterministically, so it is instant and private. Ideal for oceanography and marine-science tools, ocean-model and sensor pipelines, aquarium and aquaculture apps, and environmental dashboards. Pure local computation — no key, no third-party service, instant. Surface (atmospheric-pressure) forms. 3 compute endpoints. For the speed of sound in seawater use a sonar API; for general colligative properties a colligative-properties API.

Uptime

100.0%

Latency

77ms

Subs

3,133

Worm-gear engineering maths as an API, computed locally and deterministically — the ratio, lead-angle and efficiency numbers a machine designer or millwright sizes a worm drive with. The ratio endpoint gives the reduction = wheel teeth ÷ worm starts, so a single-start worm on a 40-tooth wheel is a big 40:1 reduction in one compact stage — the high ratio in a small package is the whole appeal of a worm drive. The geometry endpoint gives the lead (= starts × axial pitch, with axial pitch = π × module) and the lead angle = atan(lead ÷ (π × worm pitch diameter)), and tests for self-locking: a small lead angle (roughly under 5–6° for typical steel-on-bronze) means the wheel cannot back-drive the worm — invaluable for hoists and holding loads, at the cost of efficiency. The efficiency endpoint gives the mesh efficiency when the worm drives = tan(lead angle) ÷ tan(lead angle + friction angle), which is low for the small lead angles that give big ratios — often 50–70 %, which is why worm gears run warm and need good lubrication — while high-lead multi-start worms reach 90 %+; when the lead angle drops to the friction angle the drive becomes self-locking. Everything is computed locally and deterministically, so it is instant and private. Ideal for mechanical-design and gearbox tools, machine-building and CAD utilities, and engineering calculators. Pure local computation — no key, no third-party service, instant. Confirm self-locking dynamically — vibration can unlock a marginal pair. 3 compute endpoints. For spur gears use a spur-gear API; for a general ratio a gear-ratio API.

Uptime

100.0%

Latency

76ms

Subs

4,818

RC servo and PWM maths as an API, computed locally and deterministically — the pulse-width, angle and duty-cycle numbers a robotics, RC or embedded developer drives a servo with. The angle endpoint turns a pulse width into the servo angle: a hobby servo reads the width of the pulse (not a duty cycle), so the standard 1000–2000 µs maps linearly across the travel with 1500 µs at centre — angle = (pulse − min) ÷ the min-to-max span × the travel — and it flags when a pulse asks for more than the configured range so you do not drive the servo into its mechanical stops. The pulse endpoint runs it the other way, giving the pulse width a microcontroller should write for a target angle (90° is 1500 µs on a 1000–2000 µs / 180° servo), exactly what an Arduino-style servo library computes under the hood. The duty endpoint converts a pulse and a refresh frequency into the PWM period and duty cycle: a 50 Hz servo frame is 20 ms, so a 1500 µs pulse is just 7.5 % duty — the value a timer peripheral needs — and faster frames for digital servos or multirotor ESCs (e.g. 333 Hz) change it. Everything is computed locally and deterministically, so it is instant and private. Ideal for robotics and RC firmware, microcontroller and embedded tools, drone and animatronics projects, and maker calculators. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For stepper steps-per-mm use a stepper-motor API.

Uptime

100.0%

Latency

70ms

Subs

4,008

Air-fuel ratio and lambda maths for engine tuning as an API, computed locally and deterministically — the lambda, AFR and mixture numbers a tuner, ECU developer or motorsport engineer dials fuelling in with. The lambda endpoint turns a measured air-fuel ratio into lambda (the AFR divided by the fuel's stoichiometric AFR — 14.7 for gasoline) and the equivalence ratio φ = 1/lambda, classifying the mix as rich, stoichiometric or lean: a gasoline AFR of 13.0 is lambda 0.88, an 11.6 % rich mixture, the sort used at wide-open throttle for power and a cooler, safer burn. The afr endpoint runs it the other way — pick a target lambda and it gives the AFR the wideband should read — and because the AFR number is fuel-specific (E85's stoichiometric AFR is about 9.8, not 14.7) it always works from the right fuel, which is why pros tune in lambda when switching fuels. The mixture endpoint links the air the engine breathes to the fuel the injectors must add: give an air mass and a target lambda and it returns the fuel mass (or vice-versa), the heart of how an ECU sizes fuelling from measured airflow. Built-in stoichiometric ratios for gasoline, E10, E85, ethanol, methanol, diesel, LPG, propane, methane/CNG and hydrogen, or pass your own. Everything is computed locally and deterministically, so it is instant and private. Ideal for engine-tuning and dyno tools, ECU and standalone-management apps, motorsport and data-logging utilities. Pure local computation — no key, no third-party service, instant. 3 compute endpoints. For engine displacement and power use an engine API; for chemical reaction stoichiometry a stoichiometry API.

Uptime

100.0%

Latency

74ms

Subs

4,888

Underwater-sound and sonar maths as an API, computed locally and deterministically — the speed, absorption and ranging numbers a marine engineer, sonar developer or oceanographer works with. The sound-speed endpoint gives the speed of sound in seawater from the Mackenzie nine-term equation: about 1,500 m/s — far faster than in air — rising with temperature, salinity and depth, so a profile of 25 °C, 35 ppt at 1,000 m gives 1,550.7 m/s. Because the speed varies with depth, sound rays bend and form the SOFAR channel that carries whale song and signals across whole oceans. The absorption endpoint gives Thorp's sound-absorption coefficient in dB per km against frequency, with the loss over a path: seawater swallows high frequencies fast, which is why long-range sonar and whale calls are low-pitched while high-frequency sonar gives sharp images only at short range. The echo-range endpoint turns an echo sounder's or sonar's two-way travel time into the range or depth — distance = sound speed × time ÷ 2 — so a one-second round trip at 1,500 m/s is a target 750 m away, its accuracy resting on the assumed sound speed. Everything is computed locally and deterministically, so it is instant and private. Ideal for sonar and hydrophone tools, marine-survey and bathymetry apps, ocean-acoustics research, and AUV/ROV navigation utilities. Pure local computation — no key, no third-party service, instant. Standard-equation estimates over their valid ranges. 3 compute endpoints. For the speed of sound in air and Mach use a Mach-number API; for decibels a sound-level API.

Uptime

100.0%

Latency

79ms

Subs

4,681

Stepper-motor motion maths as an API, computed locally and deterministically — the steps-per-millimetre and speed numbers a 3D-printer, CNC or robotics builder configures a machine with. The leadscrew endpoint gives the steps per mm for a lead-screw or ball-screw axis: (motor steps per revolution × microstepping) ÷ the screw lead, so a 1.8° motor (200 steps) at 16 microsteps on an 8 mm-lead screw is 400 steps/mm with 2.5 µm of resolution — the value that goes straight into the firmware. The belt endpoint does the same for a belt-and-pulley axis, where the travel per motor turn is the pulley teeth × the belt pitch (GT2 belt = 2 mm), so a 20-tooth GT2 pulley gives the classic 80 steps/mm of a 3D-printer X/Y axis, and shows the speed-versus-precision trade of a bigger pulley. The speed endpoint turns a steps-per-mm and a step pulse rate into the axis speed in mm/s and mm/min — at 80 steps/mm a 40 kHz step rate is 500 mm/s, though the real limit is the motor stalling at high step rates and the controller pulse ceiling. It also notes that microstepping adds smoothness, not true accuracy, since torque per microstep falls. Everything is computed locally and deterministically, so it is instant and private. Ideal for 3D-printer and CNC firmware setup, motion-control and robotics tools, and maker calculators. Pure local computation — no key, no third-party service, instant. Ideal-geometry estimates — leave a margin below the theoretical top speed. 3 compute endpoints. For CNC surface finish use a CNC-finish API; for gear ratios a gear-ratio API.

Uptime

100.0%

Latency

82ms

Subs

3,837

Battery-pack design maths as an API, computed locally and deterministically — the voltage, capacity, energy, current and charge-time numbers an EV, e-bike, solar or robotics pack builder lays out a battery with. The configuration endpoint turns a series-parallel cell layout into the pack: cells in series add their voltages (the series count sets the pack voltage) and cells in parallel add their amp-hours (the parallel count sets the capacity), with the energy in watt-hours = voltage × capacity — a 13S4P pack of 3.6 V / 3.5 Ah cells is 46.8 V, 14 Ah and about 655 Wh from 52 cells, and it also reports the full-charge voltage (series × 4.2 V for Li-ion) to size the charger and BMS. The c-rate endpoint relates current to capacity both ways — give a C-rate to get the current, or a current to get the C-rate — because 1C draws or charges the whole capacity in an hour, so a 14 Ah pack at 2C is 28 A, and it returns the power if you pass the pack voltage. The charge-time endpoint gives the time to charge between two states of charge from the charge current. Everything is computed locally and deterministically, so it is instant and private. Ideal for EV and e-bike builders, solar and off-grid storage tools, robotics and drone packs, and battery-engineering apps. Pure local computation — no key, no third-party service, instant. Pack-design estimates — real cells taper on charge and sag under load. 3 compute endpoints. For runtime under a load use a battery API; for EV charging an EV-charging API.

Uptime

100.0%

Latency

72ms

Subs

3,638

Hydraulic-cylinder engineering maths as an API, computed locally and deterministically — the force, speed and oil-volume numbers a fluid-power designer, machine builder or hydraulics technician sizes a cylinder with. The force endpoint gives the push and pull from the bore, rod diameter and working pressure: extending, the oil acts on the full bore area, so the cylinder is strongest pushing out; retracting, it acts only on the annulus left by the rod, giving less force — a 100 mm bore with a 56 mm rod at 160 bar pushes about 125.7 kN out but pulls only 86.3 kN back, which is why a press or an excavator does its hard work on the extend stroke. The speed endpoint gives the piston speed from the pump flow (speed = flow ÷ area), so extending is the slower stroke and retracting the faster, the trade-off every circuit designer balances against force. The volume endpoint gives the swept oil volume per stroke for extend and retract, the rod displacement and the bore-to-annulus area ratio — the differential (regeneration) ratio used to speed the extend stroke in a regen circuit — so the pump, tank and lines can be sized for the larger volume. Everything is computed locally and deterministically, so it is instant and private. Ideal for fluid-power and machine-design tools, hydraulics-sizing calculators, mobile- and industrial-equipment utilities, and engineering apps. Pure local computation — no key, no third-party service, instant. Ideal-area estimates — allow for friction, back-pressure and efficiency. 3 compute endpoints. For Pascal force-multiplication use a hydraulics API; for valve sizing a valve-flow (Cv/Kv) API.

Uptime

100.0%

Latency

73ms

Subs

3,954

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

76ms

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

76ms

Subs

3,377