API marketplace

Earned Value Management (EVM) maths as an API, computed locally and deterministically — the project cost-and-schedule controls used in PMP, PRINCE2 and government contracting. The metrics endpoint takes the budget at completion (BAC), planned value (PV), earned value (EV) and actual cost (AC) — or a percent-complete and planned-percent of BAC — and returns the cost variance (CV = EV−AC), schedule variance (SV = EV−PV), the cost and schedule performance indices (CPI = EV/AC, SPI = EV/PV), the percent complete and spent, and a plain-language over/under-budget and ahead/behind-schedule read. The forecast endpoint projects the finish: the estimate at completion by three standard methods (BAC/CPI when the cost trend continues, AC + remaining budget, and the cost-and-schedule AC + (BAC−EV)/(CPI·SPI)), the estimate to complete (ETC), the variance at completion (VAC) and the to-complete performance index (TCPI) to land on either the original budget or the EAC. A CPI of 0.875 on a 1000 budget forecasts a 1143 overrun. Everything is computed locally and deterministically, so it is instant and private. Ideal for project-management, PMO, construction, aerospace and contracting app developers, project dashboards and earned-value reporting tools, and PMP/PRINCE2 training. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. This is earned-value project control; for loan or NPV cash-flow maths use a finance API.

Uptime

100.0%

Latency

82ms

Subs

4,782

Six Sigma and quality-engineering maths as an API, computed locally and deterministically — the process-capability and defect maths behind a quality programme. The capability endpoint takes a process mean, standard deviation and the upper and/or lower specification limits and returns Cp = (USL−LSL)/6σ and Cpk = min((USL−μ)/3σ, (μ−LSL)/3σ) together with Cpu, Cpl and the expected DPMO and yield from the normal tails — a centred Cpk of 1.33 is the classic capable-process target. The dpmo endpoint turns defects, units and opportunities (or a yield) into defects per million opportunities, the yield and the process sigma level using the conventional 1.5σ long-term shift — the famous six-sigma 3.4 DPMO, and 3000 DPMO landing at about 4.25 sigma. The yield endpoint rolls per-step yields into the rolled throughput yield Π(yieldᵢ) — the chance a unit passes every step defect-free — with the normalized yield and the total defects per unit, and can start from DPU instead. The normal tails come from an accurate erfc and the sigma level from an exact inverse-normal. Everything is computed locally and deterministically, so it is instant and private. Ideal for quality-engineering, manufacturing, Lean Six Sigma and process-improvement app developers, SPC and capability-study tools, and green/black-belt training. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is the capability and DPMO maths; for general descriptive statistics use a statistics API.

Uptime

100.0%

Latency

72ms

Subs

4,281

Reliability-engineering maths as an API, computed locally and deterministically — the availability, MTBF and failure maths behind SLAs and dependable systems. The availability endpoint converts between MTBF and MTTR, a target availability and the SLA "nines": give it a mean time between failures and a mean time to repair and it returns the availability A = MTBF/(MTBF+MTTR) and the downtime per year, month, week and day; give it a number of nines and it returns the budget — three nines (99.9 %) is 8.76 hours of downtime a year, five nines (99.999 %) just 5.26 minutes. The reliability endpoint computes the probability a unit survives a mission time under the exponential model R(t) = e^(−λt) with its constant hazard λ = 1/MTBF, or the Weibull model R(t) = e^(−(t/η)^β) — β below one for infant mortality, one for random failures, above one for wear-out — returning the reliability, failure probability, hazard rate and the mean life η·Γ(1+1/β). The system endpoint combines component reliabilities into a system: series (the weakest link, ΠRᵢ), parallel redundancy (1−Π(1−Rᵢ)) or k-of-n voting. Everything is computed locally and deterministically, so it is instant and private. Ideal for SRE, DevOps, hardware-reliability, safety-engineering and SLA-planning app developers, uptime-budget and redundancy-design tools, and engineering education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is reliability and availability maths; for queue wait-times use a queueing API and for live uptime checks use a monitoring service.

Uptime

100.0%

Latency

78ms

Subs

4,656

Scuba-diving and gas-planning maths as an API, computed locally and deterministically. The nitrox endpoint takes an oxygen fraction and returns the maximum operating depth (MOD) for a ppO2 limit (1.4 working, 1.6 contingency), and, for a given depth, the oxygen partial pressure, the equivalent air depth (EAD), whether the mix is within its limit and the best mix for that depth — EAN32 has a MOD of 33.75 m at 1.4 and an EAD of 24.4 m at 30 m. The gas endpoint plans breathing gas from a surface air consumption (SAC/RMV) rate: it scales consumption to depth (consumption = SAC × (1 + depth/10)), gives the litres a planned dive needs and the cylinder duration on the available gas down to a reserve, and can derive your SAC from a logged dive's pressure drop, cylinder size and time. The pressure endpoint gives the ambient pressure and the partial pressure of every gas at depth, plus the equivalent narcotic depth (END) for any blend including trimix — helium is non-narcotic, so it cuts narcosis. Metric throughout: depth in metres of sea water, where 10 m ≈ 1 bar. Everything is computed locally and deterministically, so it is instant and private. Ideal for dive-planning, dive-log, freediving and scuba-training app developers, nitrox and trimix calculators, and dive-education tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is dive-planning maths, not a decompression-model NDL — always cross-check with tables or a dive computer.

Uptime

100.0%

Latency

80ms

Subs

4,595

Casino game maths as an API, computed locally and deterministically — exact house edge, expected value and return-to-player, never a simulation. The roulette endpoint takes a wheel variant (European single-zero or American double-zero) and a bet type (straight, split, street, corner, six-line, column, dozen, red/black, odd/even, high/low, or the American basket) and returns the win probability, the payout, the expected value per unit staked and the house edge — the famous 2.70 % on every European bet, 5.26 % on American (7.89 % on the basket), and 1.35 % when the European la-partage rule is applied to even-money bets. The craps endpoint gives the exact 36-outcome dice maths for the pass line (1.41 %), don't pass (1.36 %, with its 12-push), the field (2.78 % when 12 pays 3:1) and any seven (16.67 %). The bet endpoint is fully generic: give any win probability and payout and it returns the expected value, house edge, return-to-player and the standard deviation of a unit bet — perfect for keno, slots, scratch cards or a custom wager. Everything is computed locally and deterministically, so it is instant and private. Ideal for gaming-analytics, responsible-gambling, casino-education and odds-comparison app developers, advantage-play and bankroll tools, and probability teaching. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is the game-odds maths; for Texas Hold'em hand equity use a poker API and for converting betting prices use an odds API.

Uptime

100.0%

Latency

75ms

Subs

3,692

Baseball sabermetrics as an API, computed locally and deterministically — turn raw counting numbers into the rate stats that actually rank players. The batting endpoint takes at-bats, hits, doubles, triples, home runs, walks, hit-by-pitch and sacrifice flies and returns the batting average (H/AB), on-base percentage ((H+BB+HBP)/(AB+BB+HBP+SF)), slugging percentage (total bases/AB), OPS (on-base plus slugging), isolated power (SLG−AVG) and, when strikeouts are supplied, BABIP — a classic .300/.366/.530 line comes straight out. The pitching endpoint takes innings pitched, earned runs, hits, walks, strikeouts and home runs and returns the earned run average (9·ER/IP), WHIP ((BB+H)/IP), strikeouts and walks per nine innings, the strikeout-to-walk ratio and FIP, the fielding-independent pitching estimator (13·HR + 3·(BB+HBP) − 2·K)/IP + constant. Innings pitched is a true decimal, with an exact "outs" input for the 6.1/6.2 box-score convention. Everything is computed locally and deterministically, so it is instant and private. Ideal for fantasy-baseball, sports-analytics, sabermetrics and box-score app developers, scouting and stat-line tools, and teaching material. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. This computes the stats from your numbers; for live scores, standings, teams and players use a sports-data API.

Uptime

100.0%

Latency

77ms

Subs

4,180

Real-estate investment maths as an API, computed locally and deterministically — the property-analysis layer a loan calculator leaves out. The cap-rate endpoint gives the net operating income and capitalization rate of a rental from its price, gross rent, vacancy allowance and operating expenses (NOI = gross rent × (1 − vacancy) − expenses; cap rate = NOI / price), plus the gross rent multiplier — the unlevered view a buyer compares deals on. The cash-flow endpoint adds financing: from a down payment (amount or percent), interest rate and term it amortizes the mortgage, then returns the monthly payment, annual debt service, the property cash flow, the cash-on-cash return (annual cash flow ÷ cash invested), the debt-service-coverage ratio (DSCR = NOI ÷ debt service, the figure lenders underwrite to) and the loan-to-value. The metrics endpoint runs the quick screening ratios investors filter on — the 1 % rule (monthly rent ≥ 1 % of price), gross rental yield, gross rent multiplier and price per square foot. Money in, ratios out, in one consistent currency. Everything is computed locally and deterministically, so it is instant and private. Ideal for proptech, real-estate-investment, rental-analysis and landlord app developers, deal-screening and underwriting tools, and personal-finance dashboards. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 compute endpoints. This is property-investment analysis; for pure loan amortization use a loan API and for DCF/NPV use an investment-appraisal API.

Uptime

100.0%

Latency

73ms

Subs

4,266

The Collatz conjecture (the "3n+1" or hailstone problem) as an API, computed locally and deterministically. Give it any positive integer and the sequence endpoint returns the full hailstone path — at each step an even number is halved and an odd number is tripled and incremented (3n+1) — together with the total stopping time (the number of steps to reach 1) and the peak value the sequence climbs to. Starting from 6 the path is 6, 3, 10, 5, 16, 8, 4, 2, 1 — eight steps, peaking at 16; the notoriously long start 27 takes 111 steps and soars to a peak of 9232 before collapsing. The steps endpoint returns just the stopping time and peak altitude without the whole path, for fast bulk scans of where the big climbs and long tails are. All arithmetic runs in arbitrary-precision integers so the peak stays exact even when a small starting number balloons into the millions, and a safety cap keeps every request bounded. Starting numbers up to one hundred trillion are accepted. Everything is computed locally and deterministically, so it is instant and private. Ideal for maths-education, number-theory, recreational-mathematics and puzzle app developers, sequence-and-hailstone visualisers, and teaching material on the most famous unsolved problem in arithmetic. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 compute endpoints. This is the Collatz/3n+1 sequence specifically; for prime factorisation or GCD use a number-theory API.

Uptime

100.0%

Latency

75ms

Subs

4,833

Birthday-paradox and collision-probability maths as an API, computed locally and deterministically. The probability endpoint computes the chance that at least two of n people share a birthday among d equally likely days, P = 1 − Π(1 − i/d), evaluated in log space for accuracy — the famous result that just 23 people give about a 50.7 % chance, 50 people about 97 % and 70 people about 99.9 %. The people-needed endpoint inverts it: the smallest group size to reach a target probability (23 for 50 %, 57 for 99 %), with the √(2·d·ln(1/(1−p))) approximation. The collision endpoint generalises the birthday bound to any space — pass a number of buckets or a hash size in bits — and returns the collision probability P ≈ 1 − e^(−n²/2d), the rule behind hash collisions and UUID-uniqueness estimates, where a 50 % chance needs roughly 1.177·√d items. Days and buckets default to 365. Everything is computed locally and deterministically, so it is instant and private. Ideal for probability-education, security, cryptography, hashing, data-engineering and statistics app developers, collision-risk and birthday-problem tools, and teaching material. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is the birthday/collision probability; for full distributions use a probability API.

Uptime

100.0%

Latency

80ms

Subs

4,858

Advanced 3D-solid geometry as an API, computed locally and deterministically — the shapes a basic geometry calculator leaves out. The cone-frustum endpoint gives the volume V = (π·h/3)·(R² + R·r + r²), the slant height √(h² + (R−r)²) and the lateral and total surface area of a truncated cone, the shape of buckets, lampshades and hoppers. The torus endpoint gives a doughnut’s volume 2π²·R·r² and surface area 4π²·R·r from its centre-to-tube and tube radii. The ellipsoid endpoint gives the exact volume (4/3)π·a·b·c and a Knud-Thomsen surface-area approximation accurate to better than 1.1 %. The platonic endpoint returns the volume and surface area of any of the five Platonic solids — tetrahedron, cube, octahedron, dodecahedron and icosahedron — from the edge length, using the exact golden-ratio coefficients (a unit icosahedron has volume 2.1817 and surface area 8.6603). Use a consistent length unit and get area and volume out. Everything is computed locally and deterministically, so it is instant and private. Ideal for engineering, CAD, 3D-modelling, architecture, manufacturing and maths-education app developers, volume-and-area and packaging tools, and simulation software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. These are the advanced solids; for sphere, cube, cylinder, cone and 2D shapes use a general geometry API.

Uptime

100.0%

Latency

80ms

Subs

3,185

Music-theory maths as an API, computed locally and deterministically over the twelve-tone chromatic scale. The interval endpoint gives the number of semitones and the interval name between two notes — C to G is seven semitones, a perfect fifth. The transpose endpoint shifts one or more notes up or down by a number of semitones, so C E G transposed up seven becomes G B D and a negative value transposes down. The chord endpoint returns the notes of a chord from a root and a type — major, minor, diminished, augmented, the sevenths (major7, minor7, dominant7, diminished7, half-diminished7), sixths, suspended, add9, ninth and power chords — so C major is C E G and C7 is C E G B♭. The scale endpoint returns the notes of a scale from a root and a mode — the major and three minor scales, the seven church modes, the major and minor pentatonics, blues, whole-tone and chromatic — so C major is C D E F G A B and A natural-minor is A B C D E F G. Notes use C, C#, D♭ … B, and accidental=flat spells with flats. Everything is computed locally and deterministically, so it is instant and private. Ideal for music-education, ear-training, songwriting, DAW-plugin, notation and instrument app developers, chord-and-scale tools, and practice software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. This is pitch-class theory; for the actual frequency of a note use a music-note API.

Uptime

100.0%

Latency

83ms

Subs

4,147

Phonetic and fuzzy string-matching maths as an API, computed locally and deterministically. The soundex endpoint computes the American Soundex code of a word — the first letter followed by three digits that encode its consonant sounds, ignoring case and non-letters and applying the vowel-reset and adjacent-duplicate rules — so Robert and Rupert both code to R163, Smith and Smyth to S530, and the classic tricky cases Ashcraft (A261), Tymczak (T522) and Pfister (P236) come out right. The levenshtein endpoint computes the edit distance between two strings (the minimum insertions, deletions and substitutions, optionally case-sensitive) and a 0–100 % similarity, so kitten → sitting is three edits and about 57 % similar. The compare endpoint combines both: it reports whether two strings share a Soundex code (sound alike) and their Levenshtein similarity (spelled alike), and flags a likely match when the codes agree or the similarity is at least 80 %. Everything is computed locally and deterministically, so it is instant and private. Ideal for data-deduplication, CRM, fuzzy-search, autocomplete, genealogy and data-cleaning app developers, name-matching and record-linkage tools, and search software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is phonetic and edit-distance matching; for full-text search use a search API.

Uptime

100.0%

Latency

76ms

Subs

4,783

EU VAT identification number format validation as an API, computed locally and deterministically. The validate endpoint takes a VAT number, strips spaces, dots and hyphens, reads the two-letter country prefix and checks the remaining body against that member state’s official structure — Germany’s nine digits, Austria’s U-plus-eight, the Netherlands’ nine-digits-B-two, France’s two-character prefix plus nine digits, Italy’s eleven digits, and so on for all 27 EU countries plus Northern Ireland (XI), correctly using EL for Greece rather than GR. It returns whether the format is valid, the country, and the expected pattern, so DE123456789 and ATU12345678 pass while a German number with only eight digits or a US prefix is rejected. The format endpoint looks up the expected VAT pattern for any country code, or lists all supported ones. This is an offline structure check — a valid format does not prove the number is registered, for which a live VIES lookup is needed. Everything is computed locally and deterministically, so it is instant and private. Ideal for e-commerce, invoicing, accounting, B2B-checkout and tax-compliance app developers, VAT-field validation and onboarding tools, and finance software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This validates VAT-number format; for VAT tax rates use a VAT/tax API.

Uptime

100.0%

Latency

77ms

Subs

3,731

US bank ABA routing-number (routing transit number) validation as an API, computed locally and deterministically. The validate endpoint checks a nine-digit routing number with the official ABA checksum — 3·(d1+d4+d7) + 7·(d2+d5+d8) + (d3+d6+d9) must be a multiple of ten — ignoring hyphens and spaces, and reads the first two digits as the Federal Reserve routing symbol to name the district (01–12 are the twelve Federal Reserve Banks from Boston to San Francisco, 21–32 are thrift institutions); JPMorgan Chase’s 021000021 validates and resolves to the Federal Reserve Bank of New York, and a number with a wrong check digit is rejected. The checkdigit endpoint computes the ninth check digit from the first eight so the whole number passes. It also returns the institution identifier (digits 5–8) and the check digit. Everything is computed locally and deterministically, so it is instant and private. Ideal for fintech, banking, ACH, payroll, payment and accounting app developers, bank-account-form validation and onboarding tools, and US payment software. This is the checksum and routing-symbol structure only — it does not confirm a live bank. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. For SWIFT/BIC codes use a BIC API and for IBANs an IBAN API.

Uptime

100.0%

Latency

71ms

Subs

3,929

SWIFT/BIC business-identifier-code validation and parsing as an API, computed locally and deterministically. The validate endpoint checks that a code follows the ISO 9362 BIC structure — four letters for the institution, a two-letter ISO country code, a two-character location code and an optional three-character branch code, eight or eleven characters in total — ignoring spaces and upper-casing the input, and confirms the country code is a recognised one; DEUTDEFF (Deutsche Bank, Frankfurt) is a valid eight-character head-office BIC and DEUTDEFF500 a valid eleven-character branch BIC. The parse endpoint breaks a BIC into its institution, country, location and branch components, reports whether it is a head office or a branch (branch XXX or none means the head office), and reads the status from the location code’s second character — 0 for a test/non-SWIFT code, 1 for a passive participant and 2 for reverse billing. A BIC carries no checksum, so this is structural validation. Everything is computed locally and deterministically, so it is instant and private. Ideal for fintech, banking, payment, KYC, treasury and accounting app developers, SWIFT-code and bank-identifier tools, and onboarding flows. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This validates and parses a BIC; for IBAN account-number validation use an IBAN API.

Uptime

100.0%

Latency

79ms

Subs

3,614

ISBN validation and conversion as an API, computed locally and deterministically. The validate endpoint detects whether a code is an ISBN-10 or an ISBN-13, ignores hyphens and spaces, and verifies the check digit — ISBN-10 with the mod-11 scheme whose last character may be the letter X (for 10), and ISBN-13 with the weighted 1-3-1-3 mod-10 scheme — so 0-306-40615-2 and 978-0-306-40615-7 both validate while a wrong check digit is rejected. The checkdigit endpoint computes the trailing check digit for a 9-digit ISBN-10 stem or a 12-digit ISBN-13 stem (and recomputes it for a full code). The convert endpoint converts between the two forms: an ISBN-10 becomes an ISBN-13 by prefixing 978 and recomputing the check, and a 978-prefixed ISBN-13 converts back to ISBN-10 (979-prefixed codes have no ISBN-10 equivalent). Everything is computed locally and deterministically, so it is instant and private. Ideal for publishing, library, bookstore, catalogue, e-commerce and metadata app developers, ISBN-validation and barcode tools, and inventory systems. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is ISBN-specific validation and conversion; for generic Luhn/Verhoeff check digits use a check-digit API.

Uptime

100.0%

Latency

74ms

Subs

3,609

UTM ↔ geographic coordinate conversion as an API, computed locally and deterministically on the WGS84 ellipsoid. The from-latlon endpoint projects a latitude and longitude into the Universal Transverse Mercator grid — returning the zone (1–60), the hemisphere, the latitude band letter, and the easting and northing in metres — using the Snyder/USGS Transverse Mercator series, which is accurate to a few millimetres within a zone; New York (40.7128, −74.0060) maps to zone 18N at about 583960 E, 4507351 N, and the canonical 45°N on a central meridian gives a northing of exactly 4982950.40 m. The to-latlon endpoint inverts it, recovering the latitude and longitude from a zone, hemisphere, easting and northing. Each zone is 6° of longitude wide with a 500000 m false easting on its central meridian and a 10000000 m false northing in the southern hemisphere. Latitude is valid from −80° to 84°. Everything is computed locally and deterministically, so it is instant and private. Ideal for GIS, surveying, mapping, geospatial, drone-mapping and location app developers, coordinate-conversion and grid-reference tools, and spatial software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This is UTM on WGS84; for the polar regions use UPS and for an EPSG-code lookup use an EPSG API.

Uptime

100.0%

Latency

77ms

Subs

3,487

NATO phonetic alphabet conversion as an API, computed locally and deterministically. The spell endpoint turns any text into the international radiotelephony spelling alphabet used by aviation, the military, emergency services and call centres — letters become Alfa, Bravo, Charlie and so on (case-insensitive), digits use the ICAO forms (Niner for nine), spaces are marked, and unknown characters pass through — so SOS becomes “Sierra Oscar Sierra” and ABC123 becomes “Alfa Bravo Charlie One Two Three”. The decode endpoint reverses it, turning a string of phonetic words back into the original characters and accepting common spelling variants (Alpha or Alfa, X-ray or Xray, Juliet or Juliett, Nine or Niner), flagging any words it does not recognise. Everything is computed locally and deterministically, so it is instant and private. Ideal for aviation, radio, telecom, call-centre, customer-support, accessibility and voice app developers, spelling-out and read-back tools, and IVR systems. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This is the NATO/ICAO spelling alphabet; for Morse code use a Morse API.

Uptime

100.0%

Latency

73ms

Subs

4,924

DNA-oligo and PCR-primer maths as an API, computed locally and deterministically. The tm endpoint computes the melting temperature of a primer sequence three ways: the Wallace rule 2·(A+T) + 4·(G+C) for short oligos up to 13 nt, the Marmur–Wallace GC formula 64.9 + 41·(nGC − 16.4)/N for longer ones, and the salt-adjusted 81.5 + 0.41·%GC − 675/N + 16.6·log10[Na+] for a given sodium concentration, and recommends the right method for the length — an eight-base ATGCATGC melts at 24 °C by Wallace, a 20-base 50 %-GC primer at about 51.8 °C by Marmur. The gc-content endpoint reports the GC and AT percentages, the per-base counts and the single-stranded molecular weight. The reverse-complement endpoint returns the complement, the reverse and the reverse complement of a strand. Sequences use A/C/G/T (case-insensitive, whitespace ignored) and [Na+] is in mol/L. Everything is computed locally and deterministically, so it is instant and private. Ideal for molecular-biology, biotech, PCR, primer-design, bioinformatics and lab-automation app developers, oligo and primer calculators, and LIMS software. Estimation formulas for primer design, not a substitute for nearest-neighbour thermodynamics. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is oligo melting temperature; for population-genetics allele frequencies use a genetics API.

Uptime

100.0%

Latency

77ms

Subs

3,544

Population-dynamics maths as an API, computed locally and deterministically. The exponential endpoint applies the Malthusian model N(t) = N0·e^(r·t) — unbounded growth at a constant continuous rate r — and returns the projected population, the growth factor and the doubling time; a population of 100 growing at r = 0.05 per period reaches about 165 after ten periods. The logistic endpoint applies the bounded model N(t) = K/(1 + ((K−N0)/N0)·e^(−r·t)), where growth slows as the population approaches the carrying capacity K and is fastest at the inflection point N = K/2; starting from 10 toward a capacity of 1000 at r = 0.5, the population is about 600 after ten periods and levels off near 1000. The doubling-time endpoint gives ln2/r for a continuous rate, or the Rule-of-70 quick estimate for a percentage growth per period. The rate and time share one period (years, days, generations). Everything is computed locally and deterministically, so it is instant and private. Ideal for biology, ecology, demography, conservation, education and simulation app developers, population-projection and carrying-capacity tools, and modelling software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is population growth; for disease spread use an epidemiology API and for population-genetics allele frequencies a genetics API.

Uptime

100.0%

Latency

77ms

Subs

3,733

Epidemiology-basics maths as an API, computed locally and deterministically. The herd-immunity endpoint computes the herd-immunity threshold HIT = 1 − 1/R0 — the immune fraction of a population at which an outbreak can no longer sustain itself — from the basic reproduction number R0, and adjusts for an imperfect vaccine by dividing by its efficacy, so a disease with R0 = 3 needs about 67 % immune (74 % vaccinated with a 90 %-effective vaccine) while measles at R0 ≈ 15 needs about 93 %. The r-effective endpoint computes the effective reproduction number Re = R0 · susceptible fraction and flags whether the epidemic is growing (Re > 1) or shrinking. The final-size endpoint solves the final-epidemic-size equation Z = 1 − e^(−R0·Z) for the eventual attack rate of an unmitigated SIR epidemic — about 80 % at R0 = 2. The doubling-time endpoint gives the case-doubling time from a growth rate, or from R0 and the serial interval. Fractions are 0–1 and percentages are derived. Everything is computed locally and deterministically, so it is instant and private. Ideal for public-health, epidemiology-education, dashboard, science-communication and outbreak-planning app developers, herd-immunity and reproduction-number tools, and health software. Simple compartmental relations for education and planning, not a substitute for full epidemiological modelling. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 4 endpoints. This is epidemiology basics; for population-genetics Hardy-Weinberg use a genetics API.

Uptime

100.0%

Latency

74ms

Subs

3,980

Aviation runway wind-component maths as an API, computed locally and deterministically. The component endpoint resolves the surface wind into the two parts pilots care about for take-off and landing: the crosswind component perpendicular to the runway, wind·sin(θ), and the headwind (or tailwind) component along it, wind·cos(θ), where θ is the angle between the wind direction and the runway heading — give it the runway as a heading or a designator from 01 to 36, plus the wind direction and speed, and it returns the crosswind with the side it blows from (left or right), the headwind or tailwind, and the angle off; wind 30° off the nose at 20 knots is a 10-knot crosswind and a 17.3-knot headwind. The max-wind endpoint inverts it: the greatest total wind speed before a given crosswind limit is exceeded at a wind angle, limit / |sin θ|. Directions are in degrees (wind is where it comes FROM) and the speed unit is whatever you supply (knots, m/s). Everything is computed locally and deterministically, so it is instant and private. Ideal for aviation, pilot, flight-training, electronic-flight-bag, drone and weather-briefing app developers, runway-selection and crosswind-limit tools, and cockpit software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 2 endpoints. This is runway wind geometry; for the speed of sound and Mach number use a Mach API and for standard-atmosphere density a standard-atmosphere API.

Uptime

100.0%

Latency

81ms

Subs

4,067

Design-proportion maths as an API, computed locally and deterministically. The divide endpoint splits a length by the golden section, the division beloved of artists and designers in which the whole is to the longer part as the longer is to the shorter, both ratios equal to φ = (1+√5)/2 ≈ 1.618 — so 100 splits into a 61.8 longer segment and a 38.2 shorter one — and can also extend a single segment to its larger or smaller golden partner. The rectangle endpoint gives the other side and the area of a golden rectangle from either side, the shape that leaves a smaller golden rectangle when you remove a square. The scale endpoint builds a modular (typographic) scale — base · ratio^step across a range of steps up and down — for harmonious type sizes and spacing, taking a numeric ratio or a named musical one such as minor-third (1.2), major-third (1.25), perfect-fourth (1.333) or golden (φ); a 16-base major-third scale gives 16, 20, 25, 31.25 and so on. Lengths are unit-agnostic. Everything is computed locally and deterministically, so it is instant and private. Ideal for graphic-design, web-design, UI, typography, layout and architecture app developers, type-scale and proportion tools, and design systems. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is proportion and scale; for pixel-density and print sizing use a PPI/DPI API.

Uptime

100.0%

Latency

80ms

Subs

4,978

Cut-list maths for woodworking and material cutting as an API, computed locally and deterministically. The cuts endpoint computes how many pieces of a target length come from one stock length once the saw kerf — the width of material each cut removes — is accounted for, using pieces = floor((stock + kerf)/(piece + kerf)) since the final cut leaves no kerf, and returns the used length, the leftover offcut, the waste percentage and the total kerf loss; a 2400 mm board cut into 300 mm pieces with a 3 mm kerf yields 7 pieces with a 282 mm offcut, not the 8 you would expect ignoring the blade. The boards endpoint works out how many stock lengths a job of a given quantity needs and how many spare pieces are left over. The yield endpoint reports the overall material efficiency — total piece length divided by total stock length — for a whole cutting job. All lengths share one consistent unit (mm, cm or inches). Everything is computed locally and deterministically, so it is instant and private. Ideal for woodworking, carpentry, metal-fabrication, contractor, maker and shop-software developers, cut-list and offcut calculators, and material-ordering tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is single-length (1D) cut optimisation; for loose-material volume use a mulch/volume API.

Uptime

100.0%

Latency

79ms

Subs

4,044