API-Marktplatz

Weaving- und Webstuhl-Mathematik als API, lokal und deterministisch berechnet – die Kett-, Schuss- und Einstellungszahlen, mit denen ein Handweber einen Webstuhl einrichtet. Der Warp-Endpunkt berechnet die Gesamtzahl der Fäden und das Kettgarn für ein Projekt: Fäden = Webbreite × EPI (Fäden pro Zoll, die Einstellung), und die Kettlänge pro Faden = die Stofflänge angepasst für Aufnahme (~10 %) und Schrumpfung plus den Webstuhl-Abfall (~24 Zoll Fransen), also benötigt ein 20 Zoll breites Stück bei 12 EPI, das auf 60 Zoll gewebt wird, 240 Fäden und 600 Yards Kettgarn. Der Weft-Endpunkt berechnet das Schussgarn aus den Schussfäden pro Zoll, der Breite und der gewebten Länge: Schussfäden = PPI × gewebte Länge, jeder kreuzt die Breite plus den Einzug. Der Sett-Endpunkt wandelt die Wicklungen pro Zoll eines Garns in die Fäden pro Zoll für die Einstellung um: ein ausgeglichener Leinwandbindung ist die Hälfte der WPI, Köper zwei Drittel, Atlas drei Viertel – also setzt ein Garn, das 24 Wicklungen pro Zoll hat, bei 12 EPI für Leinwandbindung. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps für Weberei, Fasertechnik, Textilien und Handwerk, Kettfaden-Rechner und Projektplanungs-Tools sowie Weberei-Ausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Dienst, sofort. Imperiale Zoll eingeben; Yards ausgeben. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Aufnahme, Einzug und Webstuhl-Abfall haben sinnvolle Standardwerte – messen Sie Ihren eigenen Webstuhl.

Uptime

100.0%

Latenz

75ms

Subs

4,475

Kreuzstich- und Zählfaden-Mathematik als API, lokal und deterministisch berechnet – die Designgrößen und Garnnummern, mit denen ein Sticker ein Muster plant. Der Design-Endpunkt wandelt eine Stichanzahl in eine fertige Größe auf einer gegebenen Stoffanzahl um: Designgröße = Stichanzahl ÷ Stoffanzahl (Stiche pro Zoll), also ein 140×98-Stich-Muster auf 14-count Aida ergibt 10×7 Zoll (25,4×17,8 cm); es fügt den Stoff mit einem Rand hinzu (≈3 Zoll pro Seite für Rahmen und Fertigstellung), meldet die Gesamtstiche und konvertiert dasselbe Muster in eine andere Anzahl – das 140×98-Design schrumpft auf 7,8×5,4 Zoll auf 18-count. Der Garn-Endpunkt schätzt die Stränge Garn: Stränge ≈ ceil(Stiche ÷ Stiche-pro-Strang), wobei etwa 1.200 vollständige Kreuzstiche pro Strang typisch sind für zwei Fäden auf 14-count, und stellt sicher, dass Sie mindestens einen Strang pro Farbe kaufen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Kreuzstich-, Stickerei-, Nadelarbeits- und Handarbeitsmuster-App-Entwickler, Muster-und-Kit- und Stoff-Tools sowie Nadelarbeitsbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Stoffanzahl ist Stiche pro Zoll; Größen in Zoll und Zentimetern. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Garn-/Strang-Angaben sind Schätzungen – kaufen Sie ein wenig extra.

Uptime

100.0%

Latenz

78ms

Subs

3,192

Bilderrahmungs-Mathematik als API, lokal und deterministisch berechnet – die Passepartout-Schneide- und Leisten-Zahlen, mit denen ein Rahmenmacher oder Künstler einen Auftrag misst. Der Passepartout-Endpunkt dimensioniert die Passepartout-Platte um ein Kunstwerk: Die Fensteröffnung ist das Kunstwerk minus einer kleinen Überlappung an jeder Kante (≈ 0,25 Zoll, damit das Passepartout den Druck hält), und das äußere Passepartout ist das Fenster plus die Randbreiten – geben Sie einen Rand oder Ränder pro Seite, mit einem schwereren unteren Rand für ein ausgewogenes, unten betontes Passepartout, sodass ein 8×10-Druck mit einem 2-Zoll-Rand ein 7,5×9,5-Fenster und ein 11,5×13,5-Passepartout hat. Der Leisten-Endpunkt berechnet den benötigten Rahmenstab: Länge = Innenumfang + 8 × die Leistenbreite, da jede der vier 45-Grad-Gehre-Ecken eine Leistenbreite hinzufügt – ein 11,5×13,5-Rahmen mit 1,5-Zoll-Leiste benötigt 62,5 Zoll, zuzüglich etwaiger Verschnittzugabe. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Bilderrahmungs-, Maßanfertigungs-, Kunstgalerie- und DIY-Apps, Passepartout-Schneide- und Leisten-Schätztools sowie Rahmenausbildung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Imperiale Zoll-Eingabe; Längen in Zoll und Fuß. Live, nichts wird gespeichert. 2 Berechnungs-Endpunkte. Ein Planungshilfsmittel – zweimal messen, einmal schneiden.

Uptime

100.0%

Latenz

82ms

Subs

4,231

Näh- und Stoffberechnungsmathematik als API, lokal und deterministisch berechnet – die Yardage-Zahlen, mit denen ein Näher, Quilter oder Vorhangmacher ein Projekt kalkuliert. Der Yardage-Endpunkt legt zugeschnittene Teile auf einen Ballen: Teile pro Reihe = Boden(Breite ÷ Teilbreite), Reihen = ceil(Menge ÷ pro Reihe), und die Stofflänge = Reihen × Teilhöhe plus eine Verschnittzugabe – sechs 18×22-Zoll-Teile aus 44-Zoll-Quilting-Baumwolle benötigen etwa 2 Yards. Der Vorhang-Endpunkt dimensioniert Vorhänge für Fülle: Bahnen = ceil(Fensterbreite × Fülle ÷ Stoffbreite), wobei 2× ein Standard-Rafffaktor und 2,5–3× luxuriös ist, und jede Bahn ist die fertige Länge plus oberer und unterer Saum (aufgerundet auf den Musterrapport) – ein 60-Zoll-Fenster mit 2,5× Fülle auf 54-Zoll-Stoff benötigt drei Bahnen und etwa 8,3 Yards. Der Binding-Endpunkt dimensioniert Quilt-Binding: Länge = Umfang + Überlappung für Ecken und Verbindungen, Streifen = ceil(Länge ÷ Stoffbreite) in der Streifenbreite zugeschnitten. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Näh-, Quilt-, Heimdekor-, Polster- und Bastel-Apps, Stoffrechner- und Projektplanungstools sowie Nähausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Imperiale Zoll eingeben; Yards und Meter ausgeben. Live, nichts gespeichert. 3 Compute-Endpunkte. Musterrapport-Zugabe für bedruckte Stoffe hinzufügen; ein Planungswerkzeug.

Uptime

100.0%

Latenz

77ms

Subs

3,991

Bookbinding und Druckproduktions-Mathematik als API, lokal und deterministisch berechnet – die Rückenbreite und Impositionszahlen, die ein Buchdesigner, Drucker oder Self-Publisher benötigt, um ein Titelblatt zu gestalten. Der Spine-Endpunkt berechnet die Rückenbreite aus der Seitenanzahl und dem Papierbulk: Rücken = Seitenanzahl ÷ Seiten pro Zoll (die Papierspezifikation des Druckers, typischerweise ~400–500 für Buchbestand), oder Blätter × Blattkaliber, plus die Buchdeckel – ein 250-seitiges Buch auf 400-PPI-Bestand hat also einen 0,625-Zoll (15,9 mm) Rücken. Der Imposition-Endpunkt ermittelt das Bindelayout: Bei Klammerheftung wird die Seitenanzahl auf das nächste Vielfache von vier aufgerundet (ein gefalteter Bogen ergibt vier Seiten) und meldet die Leerseiten zum Auffüllen und die Bögen; bei Klebebindung oder Fadenheftung werden die Seiten in Signaturen von 8, 16 oder 32 gruppiert und die Anzahl der Signaturen, die erforderliche Gesamtseitenzahl und die Leerseiten gemeldet. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Self-Publishing, Print-on-Demand, Buchdesign, Prepress und Druck-App-Entwickler, Spine-and-Cover- und Imposition-Tools sowie Grafikdesign-Ausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Seitenanzahl zählt beide Seiten; PPI ist die Papierspezifikation. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Für Papiergewicht verwenden Sie eine Paper-API und für DPI/Auflösung eine Resolution-API.

Uptime

100.0%

Latenz

81ms

Subs

3,687

Wasserumsatz- und Zirkulationsmathematik als API, lokal und deterministisch berechnet – die Durchflussraten, mit denen ein Pooltechniker oder Aquarianer eine Pumpe dimensioniert. Der Turnover-Endpunkt setzt das Volumen eines Wasserkörpers in Beziehung zu seinem Durchfluss: Turnover-Zeit = Volumen ÷ Durchflussrate und Turnovers pro Tag = 24 ÷ Turnover-Zeit, also ein 50.000-Liter-Pool, der mit 10.000 L/h zirkuliert, hat einen Turnover in 5 Stunden, fast 5 Mal am Tag (Pools zielen normalerweise auf eine 8–12-stündige Turnover-Zeit, 2–4 Mal am Tag); geben Sie stattdessen eine Ziel-Turnover-Zeit an, und es gibt die Durchflussrate zurück, um die Pumpe zu dimensionieren. Der Aquarium-Endpunkt berücksichtigt den realen Druckverlust, der einer Pumpe Durchfluss raubt: effektiver Durchfluss = Nenndurchfluss × (1 − Druckverlust), also eine 1.500 L/h Pumpe mit 40 % Verlust bewegt tatsächlich 900 L/h, etwa 4,5× eines 200-Liter-Beckens pro Stunde; geben Sie einen Ziel-Turnovers-pro-Stunde an (Süßwasser 4–6×, bepflanzt 5–10×, Riff 10×+) und es gibt die Nennpumpe zurück, die gekauft werden muss, sodass Verluste immer noch genug Durchfluss lassen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Poolservice-, Aquarium-, Hydrokultur-, Wasserfeature- und Teich-App-Entwickler, Pumpendimensionierungs- und Zirkulationstools sowie Geräteschulung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Verwenden Sie konsistente Volumen- und Durchflusseinheiten. Live, nichts gespeichert. 2 Compute-Endpunkte. Für Pumpenleistung und Druck verwenden Sie eine Pumpen-API; für Poolchemie eine Poolchemie-API.

Uptime

100.0%

Latenz

89ms

Subs

3,899

Beekeeping und Imkerei-Mathematik als API, lokal und deterministisch berechnet – die Milben-, Brut- und Wintervorratszahlen, mit denen ein Imker ein Volk verwaltet. Der Varroa-Endpunkt wandelt eine Alkoholwäsche- oder Zuckerstaub-Zählung in die Befallsrate um: Milben pro 100 Bienen = Milbenanzahl ÷ beprobte Bienen × 100, wobei eine halbe Tasse etwa 300 Bienen entspricht, und er meldet, wenn das Volk die Behandlungsschwelle überschreitet (üblicherweise 3 Milben pro 100 Bienen oder 3 %). Der Brut-Endpunkt projiziert den Entwicklungskalender ab dem Tag, an dem ein Ei gelegt wird: Es schlüpft um Tag 3, die Zelle wird um Tag 8–10 verdeckelt und die erwachsene Biene schlüpft am Tag 16 für eine Königin, 21 für eine Arbeiterin und 24 für eine Drohne – ein Arbeiterei, das am 1. gelegt wird, schlüpft also drei Wochen später. Der Vorrats-Endpunkt dimensioniert den Winterhonig: wie viele Kilogramm das Volk je nach Klima benötigt (etwa 12 kg mild bis 35 kg streng), die entsprechende Anzahl voller Zargenrahmen (~2,25 kg pro Stück) sowie das Defizit und die Rahmen, die bei den aktuellen Vorräten zugefüttert werden müssen. Datumsarithmetik ist exakt. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Entwickler von Imkerei-, Bienenstockverwaltungs-, Hof- und Landwirtschafts-Apps, Bienenstockinspektions- und Milbenüberwachungswerkzeugen sowie Imkereiausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofortig. Daten als YYYY-MM-DD; metrische Gewichte. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Ein Planungswerkzeug – lokale Bedingungen variieren.

Uptime

100.0%

Latenz

81ms

Subs

4,732

Ahornsirup-Herstellungsmathematik als API, lokal und deterministisch berechnet – die Saft-zu-Sirup-Ausbeute und Endzahlen, um die ein Zuckerhersteller eine Saison herum plant. Der Yield-Endpoint nimmt das Saftvolumen und seinen Zuckergehalt in °Brix und gibt den Sirup zurück, der aus der Zuckerbilanz hergestellt wird (Sirup = Saft × Saft °Brix / fertig °Brix, Endabschluss bei 66,9 °Brix), das Wasser, das abgekocht werden muss, das Saft-zu-Sirup-Verhältnis und die klassische Jones-Regel von 86 (86 ÷ Saft °Brix) – die Feldregel, die bekanntermaßen etwa 43 Liter 2%igen Saft pro Liter Sirup ergibt. Der Finish-Endpoint gibt die Endtemperatur beim Abkochen: Sirup ist fertig etwa 4 °C (7,1 °F) über dem Siedepunkt von Wasser, also auf Meereshöhe etwa 104 °C / 219 °F – kalibrieren Sie auf Ihren eigenen Wassersiedepunkt, der mit der Höhe abnimmt, und beenden Sie um so viele Grad höher; er gibt auch die fertige Dichte zurück (~66,9 °Brix, SG ≈ 1,337). Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Ahornsirup-Herstellung, Selbstversorger, Craft-Food- und Farm-App-Entwickler, Verdampfer- und Ertragsplanungswerkzeuge sowie Schulungen zur Sirupherstellung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Konsistente Volumeneinheiten; Temperaturen in °C oder °F. Live, nichts wird gespeichert. 2 Compute-Endpoints. Ein Planungswerkzeug – ein Hydrometer oder Refraktometer bestätigt den Finish.

Uptime

100.0%

Latenz

76ms

Subs

4,388

Käseherstellungs-Mathematik als API, lokal und deterministisch berechnet – die Ausbeute- und Labzahlen, um die ein Handwerks- oder Hobbykäser eine Herstellung plant. Der Ausbeute-Endpunkt wendet die klassische Van-Slyke-Formel an, Ausbeute % der Milch = [(0,93 × Fett) + (Kasein − 0,1)] × 1,09 / (1 − Käsefeuchte), basierend auf dem Milchfett, dem Kasein (oder echtem Protein, da Kasein ≈ 0,78 × Protein) und der Ziel-Käsefeuchte – Vollmilch mit 3,5 % Fett und 2,5 % Kasein ergibt bei einem Cheddar mit 37 % Feuchte etwa 9,78 % des Milchgewichts, also 100 Liter ergeben etwa 10 kg Käse und es werden etwa 9,9 Liter Milch pro Kilogramm benötigt. Der Lab-Endpunkt dosiert ein Milchvolumen zum Dicklegen: einstärkiges flüssiges Lab mit etwa 0,2 ml pro Liter (auch zweifach und dreifach Stärken sowie Tabletten), verdünnt etwa 20-fach in kühlem, nicht chloriertem Wasser, bevor es eingerührt wird. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps zur Käseherstellung, Molkerei, Käserei und handwerklichen Lebensmitteln, für Arbeitsblatt- und Ausbeuteplanungswerkzeuge sowie für die Ausbildung in Molkereiwissenschaft. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Metrisch: Liter, Gramm, Prozent. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Labstärken variieren je nach Produkt – bestätigen Sie das IMCU auf dem Etikett; ein Planungshilfsmittel.

Uptime

100.0%

Latenz

85ms

Subs

3,985

Tiergestations- und Eierinkubations-Datumsberechnungen als API, lokal und deterministisch berechnet – der Zucht- und Schlupfkalender, mit dem ein Landwirt, Züchter oder Tierarzt arbeitet. Der Gestations-Endpunkt nimmt eine Spezies und ein Zuchtdatum entgegen und gibt das erwartete Fälligkeitsdatum mit dem normalen Früh-Spät-Fenster zurück: Fälligkeitsdatum = Zuchtdatum + durchschnittliche Tragzeit der Spezies, sodass eine am 1. Januar gedeckte Kuh (283 Tage) um den 11. Oktober kalbt, ein Hund (63 Tage) neun Wochen später wirft, eine Ziege 150 Tage, ein Pferd 340, ein Schwein 114 – Dutzende Spezies vom Kaninchen über das Kamel bis zum Elefanten, mit einer Überschreibung für Ihren eigenen Herdendurchschnitt. Geben Sie stattdessen ein Zielgeburtsdatum an, und es arbeitet rückwärts zum Zuchtdatum. Der Inkubations-Endpunkt macht dasselbe für Geflügel und Vögel – Huhn 21 Tage, Ente 28, Gans 30, Wachtel 18, Strauß 42 und mehr – und gibt das Schlupfdatum, das Lockdown-Datum (Eier nicht mehr wenden und Luftfeuchtigkeit erhöhen ~3 Tage vor Schlupf) sowie die Kerzendaten für Tag 7 und Tag 14 zurück. Die Datumsarithmetik ist exakt, einschließlich Schaltjahre. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps für Viehbestand, Zucht, Tierarztpraxis, Farmmanagement und Brütereien, für Trächtigkeitsrechner- und Zuchtkalender-Tools sowie für landwirtschaftliche Bildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Daten als YYYY-MM-DD. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Durchschnittswerte, keine tierärztliche Vorhersage.

Uptime

100.0%

Latenz

78ms

Subs

4,515

Kerzenherstellungs-Mathematik als API, lokal und deterministisch berechnet – die Wachs-, Duft- und Brenndauerzahlen, mit denen ein Kerzenhersteller eine Charge skaliert. Der Rezept-Endpunkt dimensioniert einen Guss anhand des Behälterwasservolumens: Wachs (g) pro Kerze = Volumen (ml) × Füllgrad × Wachsdichte (Soja ≈ 0,9, Bienenwachs ≈ 0,96, Paraffin ≈ 0,9 g/ml), also benötigt ein 250-ml-Glas bei 80 % Füllung 180 g Sojawachs; es fügt das Duftöl mit dem Lastprozentsatz hinzu (üblicherweise 6–10 %, niemals über dem Maximum des Wachses) und multipliziert alles mit der Anzahl der Kerzen für das Gesamtwachs, den Gesamtduft und das Chargengewicht. Der Brenn-Endpunkt schätzt, wie lange eine Kerze brennt: Brenndauer ≈ Wachsgramm ÷ Brennrate, wobei eine typische Behälterkerze etwa 7–9 g Wachs pro Stunde verbraucht. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Kerzenherstellungs-, Raumduft-, Handwerks- und Maker-Apps, Chargenrechner- und Rezept-Tools sowie für die Kerzenherstellungs-Ausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Metrisch: Milliliter, Gramm, Prozent. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Ein Planungshilfsmittel – Gusstests und Ihr Wachsdatenblatt haben immer Vorrang.

Uptime

100.0%

Latenz

88ms

Subs

3,785

Kaffeeröst-Mathematik als API, lokal und deterministisch berechnet – die Röstprofil-Zahlen, die ein Heim- oder Spezialitätenröster von Charge zu Charge verfolgt. Der Loss-Endpunkt berechnet die Gewichtsverlustbeziehung aus zwei beliebigen Werten: Grüngewicht, Röstgewicht und Verlustprozentsatz: Gewichtsverlust % = (grün − geröstet) / grün × 100, also 1 kg Grün, das auf 840 g fällt, ist ein Verlust von 16 %, ein Ziel von 15 % ergibt 850 g, und um 800 g Geröstetes abzupacken, benötigt man 952 g Grün (geröstet ÷ (1 − Verlust%)). Helle Röstungen verlieren etwa 12–14 %, mittlere 15–17 %, dunkle 18–20 %. Der Development-Endpunkt berechnet die Entwicklungszeit und das Development Time Ratio (DTR) aus der Gesamtröstzeit und der First-Crack-Zeit – DTR = (gesamt − first crack) / gesamt × 100, wobei die meisten Röster etwa 20–25 % anstreben; Zeiten werden als Sekunden oder mm:ss akzeptiert. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Kaffeeröst-, Rösterei-, Spezialitätenkaffee- und Röstprotokoll-Apps, Profil- und Chargen-Tools sowie Röstausbildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Gewichte in Gramm, Zeiten in Sekunden oder mm:ss. Live, nichts wird gespeichert. 2 Compute-Endpunkte. Dies ist Röstprofil-Mathematik; für Brühverhältnisse verwenden Sie eine Kaffeezubereitungs-API.

Uptime

100.0%

Latenz

77ms

Subs

4,761

Seifenherstellungs- und Verseifungsmathematik als API, lokal und deterministisch berechnet – die Laugenberechnungszahlen, die jeder Kalt- und Heißprozess-Seifenhersteller benötigt, mit eingebauter Sicherheitsmarge. Der Laugen-Endpunkt nimmt eine Liste von Ölen als Öl:Gramm-Paare entgegen (Oliven-, Kokos-, Palm-, Shea-, Rizinus-, Schmalz-, Talg- und einige Dutzend weitere, jede mit ihrem Standard-SAP-Wert) und gibt das Natriumhydroxid (NaOH) oder Kaliumhydroxid (KOH) zurück, um sie zu verseifen: Lauge = Σ(Ölgramm × SAP) × (1 − Überfettung), also benötigt 1 kg Kokosöl bei 5 % Überfettung 169,1 g NaOH (oder 263,6 g 90 %-reines KOH für Flüssigseife). Es dimensioniert das Wasser nach Laugen-Wasser-Verhältnis, Prozentsatz der Öle oder Laugenlösungskonzentration, fügt den Duft (ein paar Prozent der Öle) hinzu und summiert das Batch-Gewicht. Der Form-Endpunkt dimensioniert ein Batch auf eine Form: Öle zum Füllen ≈ Volumen(cm³) × 0,40, aus einem Volumen oder Länge × Breite × Höhe. SAP-Werte sind Gramm NaOH pro Gramm Öl. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Seifenherstellungs-, Kosmetik-, Handwerks- und Maker-App-Entwickler, Laugenrechner- und Rezepttools sowie Seifenherstellungsbildung. Reine lokale Berechnung – kein Key, kein Drittanbieterdienst, sofort. Metrisch: Gramm, cm³, Prozent. Live, nichts gespeichert. 2 Compute-Endpunkte. Lauge ist ätzend – Schutz tragen und ein neues Rezept doppelt überprüfen; dies ist eine Planungshilfe.

Uptime

100.0%

Latenz

77ms

Subs

4,002

Weinbereitungs- und önologische Mathematik als API, lokal und deterministisch berechnet – die Mostkorrektur-, Sulfit- und Säurewerte, die ein Hobby- oder Kleinchargen-Winzer einstellt. Der Zucker-Endpunkt liest den Most als Brix oder spezifisches Gewicht, gibt den potenziellen Alkohol (potenzieller Alkoholgehalt = (SG − 1) × 131,25) und berechnet den Chaptalisierungszucker, um einen Ziel-Alkoholgehalt zu erreichen – Zucker (g) = Volumen(L) × Δ potenzieller-Alkoholgehalt × 16,83, da etwa 17 g/L Zucker zu etwa 1 % Alkohol vergären. Der SO2-Endpunkt behandelt den Sulfitschutz: Er rechnet zwischen freiem und molekularem SO2 beim pH-Wert des Weins um (molekulares SO2 = freies / (1 + 10^(pH − 1,81)), zielt auf die schützenden 0,8 mg/L molekulares SO2 ab, zeigt, wie das benötigte freie SO2 mit sinkendem pH-Wert drastisch abnimmt, und dosiert Kaliummetabisulfit (57,6 % SO2) und Campden-Tabletten (~0,44 g pro Stück), um ein Ziel-freies SO2 in einem gegebenen Volumen zu erreichen. Der Säure-Endpunkt verschiebt die titrierbare Säure auf einen Zielwert mit Weinsäure zur Erhöhung (Gramm = Δ-Säure × Volumen) oder Kaliumbicarbonat zur Senkung. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps für Weinbereitung, Cidre, Met, Hausfermentation und Craft-Getränke, Mostrechner und Kellerwerkzeuge sowie önologische Bildung. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Metrisch: Liter, Gramm, g/L, mg/L. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Ein Planungswerkzeug – Ihre Laborwerte und Ihr Gaumen haben immer Vorrang. Für Bier-ABV aus der Stammwürze verwenden Sie eine Homebrauing-API.

Uptime

100.0%

Latenz

82ms

Subs

3,495

Fleischpökel- und Charcuterie-Mathematik als API, lokal und deterministisch berechnet – die Pökelsalz-, Salz- und Nitritwerte, mit denen ein Hobby-Charcutier oder Metzger arbeitet, mit der wichtigsten Sicherheitsprüfung. Der Cure-Endpunkt plant eine Gleichgewichtstrockenpökelung aus dem Fleischgewicht: Pökelsalz-Gramm = Ziel-ppm × Fleisch ÷ (0,0625 × 1.000.000), also etwa 2,5 g Pökelsalz #1 pro Kilogramm ergibt die klassischen 156 ppm Nitrit (deutlich unter dem Grenzwert von 200 ppm), plus Salz und Zucker als konfigurierbarer Prozentsatz des Fleisches, das Salz, das die Pökelsalzmischung selbst trägt, und – bei Pökelsalz #2 – das zugesetzte Nitrat für lang gereifte Salami. Der Brine-Endpunkt dimensioniert eine Nasspökelung: Salz = Wasser × Salzgehalt %, mit den Salometer-Graden (eine gesättigte 26,45 %-Lake entspricht 100°), und einer optionalen Pökelsalzdosis, die den Nitrit-ppm-Wert über Fleisch und Lake für eine Gleichgewichtssole zurückgibt. Pökelsalz #1 besteht zu 6,25 % aus Natriumnitrit; Pökelsalz #2 enthält zusätzlich 4 % Nitrat. Alles wird lokal und deterministisch berechnet, daher sofort und privat. Ideal für Entwickler von Apps für Charcuterie, Metzger, Räuchern, Wurstherstellung und Lebensmittelhandwerk, Pökelrechner- und Rezepttools sowie kulinarische Schulungen. Reine lokale Berechnung – kein Key, kein Drittanbieter-Service, sofort. Metrisch: Gramm, Milliliter, Prozent. Live, nichts wird gespeichert. 2 Compute-Endpunkte. DIES IST EINE BERECHNUNGSHILFE – befolgen Sie stets ein getestetes, zugelassenes Pökelrezept; Nitrit ist in Überdosierung giftig.

Uptime

100.0%

Latenz

77ms

Subs

3,547

Hydroponik- und Indoor-Grow-Mathematik als API, lokal und deterministisch berechnet – die Nährstoffstärke- und Wachstumslichtzahlen, die ein Züchter täglich einstellt. Der ec-Endpunkt konvertiert zwischen elektrischer Leitfähigkeit (EC in mS/cm) und dem PPM/TDS-Wert auf der Skala, die ein Messgerät verwendet: Die 500er (NaCl, US) Skala wandelt EC 2,0 in 1000 ppm um, die 700er (KCl) Skala in 1400 ppm und die 640er (EU) Skala in 1280 – die Quelle endloser Verwirrung zwischen Messgeräten. Der dli-Endpunkt berechnet das tägliche Lichtintegral, DLI = PPFD × Photoperiode × 3600 ÷ 1.000.000, die gesamten Mol Licht, die eine Pflanze an einem Tag erhält (Blattgemüse benötigt etwa 12–17, fruchttragende Pflanzen 20–30+), und kehrt es um zur PPFD, die eine Leuchte liefern muss, um ein Ziel-DLI über eine bestimmte Tageslänge zu erreichen. Der reservoir-Endpunkt gleicht einen Tank auf eine Ziel-EC aus: wie viel reines Wasser hinzugefügt werden muss, um eine zu starke Lösung zu verdünnen (W = V × (aktuell/Ziel − 1)), oder wie viel konzentrierte Stammlösung hinzugefügt werden muss, um sie zu erhöhen. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Apps für Hydroponik, Vertical Farming, kontrollierte Umweltlandwirtschaft, Grow-Räume und intelligente Gärten, für Dosierungs- und Beleuchtungswerkzeuge sowie für den gartenbaulichen Unterricht. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. EC in mS/cm, Volumen in Litern, PPFD in µmol/m²/s. Live, nichts wird gespeichert. 3 Berechnungsendpunkte. Geben Sie Ihre TDS-Skala an; bestätigen Sie mit einem kalibrierten Messgerät.

Uptime

100.0%

Latenz

74ms

Subs

4,829

Schwimmbad-Wasserchemie-Mathematik als API, lokal und deterministisch berechnet – die Dosierungs- und Wasserbilanzzahlen, die ein Pool-Service-Techniker oder -Besitzer bei jedem Besuch durchführt. Der Chlor-Endpunkt berechnet, wie viel eines Produkts hinzugefügt werden muss, um das freie Chlor von aktuellen auf einen Ziel-ppm in einem gegebenen Volumen zu erhöhen: Dosis (g) = Δppm × Liter / 1000 ÷ der verfügbare Chloranteil des Produkts, mit integrierten Stärken für flüssiges Chlor (12,5 %), Haushaltsbleiche (6 %), Cal-Hypo (65 %), Dichlor (56 %) und Trichlor (90 %) oder Ihren eigenen – um 50.000 Liter um 2 ppm zu erhöhen, werden 800 g flüssiges Chlor oder 154 g Cal-Hypo benötigt. Der LSI-Endpunkt berechnet den Langelier-Sättigungsindex, LSI = pH + Temperaturfaktor + Calciumfaktor + Alkalinitätsfaktor − 12,1, das Standardmaß dafür, ob Wasser korrosiv (unter −0,3, greift Putz und Metall an), ausgewogen (−0,3 bis +0,3) oder kalkbildend (über +0,3) ist, mit einer Cyanursäure-Korrektur der Carbonatalkalinität. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Pool-Service-, Spa-, Wasseraufbereitungs- und Hauswartungs-Apps, Dosierungs- und Wasserbilanz-Tools sowie Poolpflege-Ausbildung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Dienst, sofort. Metrisch: Liter, ppm (mg/L), °C. Live, nichts wird gespeichert. 2 Berechnungs-Endpunkte. Immer mit einem Testkit bestätigen – dies ist eine Hilfe, kein Ersatz. Für das Poolwasservolumen verwenden Sie eine Pool-Geometrie-API.

Uptime

100.0%

Latenz

80ms

Subs

4,962

NEC-Rohrfüll- und Abzweigdosen-Füllberechnungen als API, lokal und deterministisch berechnet – die elektrotechnischen Berechnungen, die ein Elektriker oder Kalkulator bei jedem Durchlauf durchführt. Der Rohrfüll-Endpunkt nimmt einen Satz von Leitern (als Größe:Anzahl-Paare, z. B. 12:3,10:2) und eine Rohrhandelsgröße und gibt die Querschnittsfläche des Leiters, die Innenfläche des Rohrs, den Füllgrad und zurück, ob er innerhalb der NEC-Kapitel-9-Grenze bleibt – 53 % für einen einzelnen Leiter, 31 % für zwei, 40 % für drei oder mehr – also neun #12 THHN füllen ein halbes Zoll EMT zu 39 % (legal), aber zehn nicht. Der Abzweigdosen-Füll-Endpunkt wendet NEC 314.16(B) an: Jeder Leiter addiert seinen Freiraum (2,00 in³ für #14, 2,25 für #12 usw.), ein Gerätejoch zählt als zwei, interne Kabelklemmen als eins und alle Erdungsleiter zusammen als eins – alle mit dem Volumen des größten Leiters – um die minimale Abzweigdosen-Größe zu ermitteln, die gegen ein angegebenes Dosenvolumen geprüft wird. Verwendet die THHN/THWN- und EMT-Flächen aus NEC Kapitel 9. Alles wird lokal und deterministisch berechnet, daher sofort und privat. Ideal für Elektroinstallations-, Kalkulations-, Prüf- und Elektriker-App-Entwickler, Rohr- und Dosenbemaßungswerkzeuge sowie Auszubildendentraining. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Imperial: Quadratzoll und Kubikzoll. Live, nichts gespeichert. 2 Berechnungsendpunkte. Immer gegen die verabschiedete Code-Ausgabe prüfen – dies ist eine Kalkulationshilfe, keine Inspektion.

Uptime

100.0%

Latenz

68ms

Subs

3,256

Aktien-Dividenden- und Bewertungsgrundlagen als API, lokal und deterministisch berechnet – die Pro-Aktie-Kennzahlen, nach denen Value- und Einkommensinvestoren filtern. Der Dividenden-Endpunkt nimmt einen Aktienkurs und eine jährliche Dividende (pro Aktie oder Gesamtdividenden ÷ Aktien) entgegen und gibt die Dividendenrendite zurück, und mit dem Gewinn pro Aktie die Ausschüttungsquote (Dividende ÷ EPS), die Dividendenabdeckung (EPS ÷ Dividende) und die Thesaurierungsquote – eine Dividende von 2 $ bei einem Aktienkurs von 50 $ ergibt 4 %, und bei einem EPS von 4 $ ist eine Ausschüttungsquote von 50 % zweimal abgedeckt. Der Bewertungs-Endpunkt berechnet das Kurs-Gewinn-Verhältnis, die Gewinnrendite, das PEG-Verhältnis im Verhältnis zu einer Wachstumsrate, das Kurs-Buchwert-Verhältnis und die Graham-Zahl √(22,5 · EPS · Buchwert) – Benjamin Grahams grobe Obergrenze für den fairen Wert. Der ddm-Endpunkt führt das Gordon-Wachstums-Dividenden-Discount-Modell aus, fairer Wert = D1 ÷ (r − g) aus der Dividende des nächsten Jahres, der erforderlichen Rendite und der ewigen Wachstumsrate, und kennzeichnet im Vergleich zu einem Marktpreis, ob die Aktie unter- oder überbewertet erscheint, sowie die impliziten Eigenkapitalkosten. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Investitions-, Broker-, Robo-Advisor-, Dividenden-Screener- und Fintech-Apps, Aktienbewertungs- und Einkommensportfolio-Tools sowie Finanzbildung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Service, sofort. Live, nichts wird gespeichert. 3 Berechnungs-Endpunkte. Dies sind Bewertungskennzahlen aus Ihren Eingaben; für Live-Kurse verwenden Sie eine Marktdaten-API und für Projekt-DCF/NPV eine Investitionsbewertungs-API.

Uptime

100.0%

Latenz

77ms

Subs

4,714

Trading-Risikomanagement-Mathematik als API, lokal und deterministisch berechnet – die Positionsgrößen- und Geldmanagement-Zahlen, die jeder disziplinierte Trader vor einem Trade berechnet. Der Positionsgrößen-Endpunkt ist instrumentenunabhängig: Aus einem Kontostand, dem Prozentsatz, den Sie bereit sind zu riskieren, einem Einstiegs- und einem Stop-Loss gibt er die Positionsgröße in Einheiten (Aktien, Kontrakte, Lots oder Coins), das Risikokapital und, mit einem Ziel, den potenziellen Gewinn und das Risiko-Ertrags-Verhältnis zurück – riskieren Sie 1 % eines 10.000 $-Kontos bei einem 50-Pip-Stop und Sie handeln 0,2 Lots und verlieren genau 100 $, wenn der Stop erreicht wird. Der Pip-Wert-Endpunkt gibt den Forex-Pip-Wert für eine Lot- oder Einheitengröße in der Kurswährung an, mit einem Kurs von Kurswährung zu Kontowährung für Nicht-Kontopaare – ein Standard-Lot bei einem Pip von 0,0001 entspricht 10 Einheiten der Kurswährung. Der Kelly-Endpunkt berechnet den optimalen Kelly-Einsatzanteil f* = W − (1−W)/R aus einer Gewinnrate und dem Gewinn/Verlust-Auszahlungsverhältnis (oder durchschnittlichem Gewinn und Verlust), plus den Half-Kelly, den viele Trader bevorzugen, und den Erwartungswert pro Einheit, wobei angezeigt wird, ob der Vorteil überhaupt positiv ist. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Trading-Journalen, Brokern, Prop-Firmen, Backtesting- und Fintech-Apps, Positionsgrößen- und Risikomanagement-Tools sowie für die Handelsausbildung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Service, sofort. Live, nichts wird gespeichert. 3 Berechnungs-Endpunkte. Dies ist Risiko- und Positionsgrößen-Mathematik; für Wechselkursumrechnungen verwenden Sie eine Währungs-API und für Optionspreise eine Black-Scholes-API.

Uptime

100.0%

Latenz

79ms

Subs

4,328

Masonry Estimating Mathematik als API, lokal und deterministisch berechnet – die Ziegel-, Block- und Mörtelmengen, mit denen ein Maurer, Bauunternehmer oder Kalkulator arbeitet. Der Ziegel-Endpunkt berechnet, wie viele Ziegel eine Wand benötigt, basierend auf ihrer Fläche (oder Länge × Höhe in Fuß): Ziegel pro Quadratfuß = 144 / ((Ziegellänge + Fuge) × (Ziegelhöhe + Fuge)), sodass ein Standard-Modulziegel mit einer 3/8-Zoll-Mörtelfuge auf die bekannten 6,86 Ziegel pro Quadratfuß kommt – eine 100 ft² große Wand benötigt 686 Ziegel, zuzüglich eines Verschnittzuschlags und der Mörtelsäcke (etwa 7 pro 1000 Ziegel). Der Block-Endpunkt macht dasselbe für Betonsteine: ein Standard-CMU 16×8 Zoll mit einer 3/8-Zoll-Fuge ergibt 1,125 Blöcke pro Quadratfuß, mit etwa 2,5 Mörtelsäcken pro 100 Blöcke. Beide Endpunkte akzeptieren benutzerdefinierte Steinabmessungen und Fugenstärken, fügen einen konfigurierbaren Verschnittprozentsatz hinzu und runden auf ganze Einheiten auf. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Bau-, Maurer-, Baustoff- und Heimwerker-Apps, für Mengenermittlungs- und Materialkalkulationswerkzeuge sowie für Handwerksrechner. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter, sofort. Imperiale Einheiten (Zoll und Quadratfuß). Live, nichts wird gespeichert. 2 Berechnungsendpunkte. Dies ist eine Ziegel-/Block- und Mörtelkalkulation; für Betonvolumen verwenden Sie eine Beton-API und für Trockenbau eine Trockenbau-API.

Uptime

100.0%

Latenz

75ms

Subs

3,732

Fracht- und Logistikberechnungen als API, lokal und deterministisch berechnet – die LTL-Frachtklasse und Ladungsplanungszahlen, mit denen ein Versender, Spediteur oder Lager arbeitet. Der Frachtklassen-Endpunkt berechnet die Dichte (Gewicht ÷ Kubikfuß) einer Sendung und ordnet sie der NMFC-dichtebasierten Frachtklasse zu – der 18-stufigen Skala von Klasse 50 (dichteste, günstigste) bis 500 (leichteste) – sodass eine 200 lb schwere Palette mit den Maßen 48×40×48 Zoll 3,75 lb/ft³ ergibt und in Klasse 250 fällt. Der Paletten-Endpunkt palettiert einen Karton: Er nimmt die bessere der beiden Grundflächenausrichtungen für Kartons pro Lage, füllt die nutzbare Stapelhöhe in Lagen und gibt die Kartons pro Palette zurück, begrenzt durch das kleinere von Volumen und Gewichtsgrenze, mit dem Frachtgewicht und der Stapelhöhe (standardmäßig eine 48×40 GMA-Palette). Der Container-Endpunkt belädt einen 40-Fuß-High-Cube-Container (oder beliebige von Ihnen angegebene Maße): wie viele Einheiten passen durch achsenausgerichtetes Stapeln und durch Nutzlast, welcher der begrenzende Faktor ist, das Gesamtgewicht und die Volumenauslastung. Alles wird lokal und deterministisch berechnet, daher ist es sofortig und privat. Ideal für Entwickler von Logistik-, Speditions-, 3PL-, Lagerverwaltungs- und Lieferketten-Apps, LTL-Tarif- und Ladungsplanungstools sowie Versandrechnern. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Service, sofortig. Imperiale Einheiten (Zoll, Pfund, Kubikfuß), da die NMFC-Skala US-basiert ist. Live, nichts wird gespeichert. 3 Berechnungsendpunkte. Dies ist Frachtklassen- und Ladungsplanungsmathematik; für das Abrechnungsgewicht von Einzelpaket-Kuriersendungen verwenden Sie eine Volumengewichts-API.

Uptime

100.0%

Latenz

76ms

Subs

4,094

Restaurant-Food-Costing-Mathematik als API, lokal und deterministisch berechnet – die Menü-Engineering- und Kostenkontrollzahlen, die eine Küche verwendet. Der Rezept-Endpunkt summiert ein Gericht aus seinen Zutatenzeilenkosten (oder Mengen × Einheitspreise), dividiert durch den Ausbeutefaktor (1 − Abfall %), sodass Verschnitt und Schrumpf die wahren Kosten erhöhen, und teilt es auf die Portionen auf, um Kosten pro Teller zu erhalten – und gegen einen Menüpreis gibt er den Food-Cost-Prozentsatz und den Bruttogewinn zurück. Der Teller-Endpunkt bewertet ein Gericht auf zwei Arten: Gib einen Menüpreis an und erhalte den Food-Cost-Prozentsatz und den Aufschlagsfaktor, oder gib einen Ziel-Food-Cost-Prozentsatz an und erhalte den vorgeschlagenen Menüpreis (ein Ziel von 30 % entspricht einem Aufschlag von 3,33×), plus Bruttogewinn, Bruttomarge und, mit Arbeitskosten, den Prime-Cost-Prozentsatz. Der Perioden-Endpunkt wandelt Lagerbewegungen in die Kosten der verkauften Waren um – COGS = Anfangsbestand + Einkäufe − Endbestand – und den Food- oder Pour-Cost-Prozentsatz im Verhältnis zum Umsatz, die wichtigste Kennzahl jeder Gewinn- und Verlustrechnung (28–35 % für Lebensmittel, 18–24 % für Getränke). Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Restaurant-Technologie, POS, Küchenmanagement, Catering- und Hospitality-Apps, Menü-Engineering- und Rezeptkosten-Tools sowie Kochschul-Training. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieter-Service, sofort. Live, nichts wird gespeichert. 3 Compute-Endpunkte. Dies ist Food-Cost- und Menüpreis-Mathematik; für Einheitenumrechnung verwenden Sie eine Koch-API und für generische Margen-Mathematik eine Preis-API.

Uptime

100.0%

Latenz

74ms

Subs

4,982

Overall Equipment Effectiveness (OEE) und Lean-Manufacturing-Mathematik als API, lokal und deterministisch berechnet – die Produktivitätskennzahl der Fabrikhalle hinter TPM und kontinuierlicher Verbesserung. Der oee-Endpoint nimmt die geplante Produktionszeit, Ausfallzeit, die Gesamt- und Gutstückzahlen sowie die ideale Zykluszeit (Sekunden pro Stück oder eine ideale Rate in Stücken pro Minute) entgegen und gibt die drei Faktoren sowie ihr Produkt zurück: Verfügbarkeit = Laufzeit / geplante Zeit, Leistung = ideale Zeit für die hergestellten Teile / Laufzeit, Qualität = Gut / Gesamt, und OEE = Verfügbarkeit × Leistung × Qualität – das Lehrbuchbeispiel einer 420-minütigen Schicht mit 47 Minuten Ausfall, 19.271 Teilen und 423 Ausschuss ergibt genau 74,79 % (88,81 % × 86,11 % × 97,80 %). Es zeigt auch die Ansicht der sechs großen Verluste: Verfügbarkeitsverlust, Leistungsverlust (Geschwindigkeit) in Teilen, Qualitätsverlust und die voll produktive Stückzahl. Der takt-Endpoint gibt die Taktzeit = verfügbare Zeit / Kundennachfrage (der Takt, den die Linie einhalten muss), die erforderliche Rate und – bei gegebener Zykluszeit oder einem Gesamtarbeitsinhalt – die Linienkapazität, Auslastung, ob sie die Nachfrage erfüllt und die Mindestanzahl an Arbeitsstationen mit der Linienabstimmungseffizienz. Alles wird lokal und deterministisch berechnet, daher ist es sofort und privat. Ideal für Entwickler von Fertigungs-, Smart-Factory-, MES-, IoT-Dashboard- und Lean/TPM-Apps, Produktionslinienüberwachungs- und kontinuierliche Verbesserungswerkzeuge sowie industrielle Ingenieurausbildung. Reine lokale Berechnung – kein Schlüssel, kein Drittanbieterdienst, sofort. Live, nichts gespeichert. 2 Compute-Endpoints. Dies ist OEE- und Takt-Mathematik; für Gerätezuverlässigkeit/MTBF verwenden Sie eine Zuverlässigkeits-API.

Uptime

100.0%

Latenz

78ms

Subs

4,575