Tube béton

Le moteur modélise un cylindre circulaire droit : le rayon est la moitié du diamètre après conversion des pouces en pieds, le volume en pieds cubes est pi fois le rayon au carré fois la hauteur, les yards cubes divisent ce volume par vingt-sept, et les sacs plafonnent la division des pieds cubes par le rendement d’un sac de quatre-vingts livres, sauf si vous remplacez bag_volume. Un diamètre ou une hauteur nuls ou négatifs sont rejetés avec invalid_input. Les appels API réussis sont facturés à $0.002 ; une validation en échec n’est pas facturée.

Comment le cubage du tube et le nombre de sacs sont calculés

Le décompte approximatif de sacs divise les pieds cubes par bag_volume, le rendement en pieds cubes d’un sac, puis plafonne à un entier car les magasins vendent des sacs entiers. Lorsque bag_volume est omis, le calculateur utilise 0.6 pieds cubes, le rendement publié d’un sac typique de quatre-vingts livres, et positionne bag_volume_defaulted à true pour que les clients API voient que la taille de sac a été supposée. Le pipeline est une arithmétique flottante déterministe, sans graines aléatoires, sans horloge murale et sans appels réseau, de sorte que des entrées identiques produisent toujours le même JSON. Le diamètre et la hauteur doivent être strictement positifs : les cotes nulles ou négatives sont rejetées avec invalid_input car un tube non positif ne peut pas contenir de béton. bag_volume, lorsqu’il est fourni, doit aussi être strictement positif pour que le ratio soit défini. spare_volume indique combien de rendement en trop le nombre de sacs arrondi couvre au-delà du cylindre nu, utile lorsque vous voulez une petite marge sans inventer un champ séparé de pourcentage de perte.

Ce que vous envoyez et ce que vous recevez

Envoyez deux nombres finis obligatoires : diameter pour le diamètre intérieur du coffrage tubulaire en pouces, et height pour la hauteur de coulage en pieds. Envoyez éventuellement bag_volume comme le rendement en pieds cubes d’un sac ; si vous l’omettez, la valeur par défaut 0.6 s’applique. Les alias d, dia et tube_diameter correspondent à diameter ; les alias h, length, depth et tube_height correspondent à height. Champs obligatoires manquants, chaînes non numériques, NaN et Infinity échouent avec invalid_input et ne sont pas facturés. Lorsque diameter ou height est nul ou négatif, la requête échoue avec un message indiquant que la cote doit être positive, afin qu’un formulaire mette le champ en évidence au lieu de renvoyer un volume nul ou négatif. En cas de succès la réponse renvoie les entrées nettoyées, radius_feet, volume_cubic_feet, volume_cubic_yards, le bag_volume utilisé et s’il a été pris par défaut, bags_exact, bags entier, spare_volume, un unit_note précisant que le diamètre est en pouces et la hauteur en pieds, et une courte chaîne formula pour la documentation. Un tube de douze pouces sur quatre pieds avec le rendement de sac par défaut est un contrôle classique : les pieds cubes valent pi, les yards cubes valent pi sur vingt-sept, bags_exact vaut pi sur 0.6 et bags plafonne à six. Un autre contrôle utile est un moule de huit pouces sur trois pieds avec bag_volume 0.45 pour des sacs de soixante livres : la même identité du cylindre, un décompte d’achat différent. Le prix des appels API réussis est la base publiée de $0.002 par item ; les échecs de validation ne consomment pas le solde prépayé. Les limites supérieure et inférieure gardent finis les produits intermédiaires : chaque champ doit être au moins un positif minuscule et au plus un plafond publié afin qu’un isolement Worker n’émette jamais Infinity.

Où un calculateur de tube béton gagne sa place

Les équipes de clôture et de terrasse coulent de nombreux pieux ronds identiques à partir d’un planning de diamètres et de profondeurs ; un endpoint déterministe qui renvoie les yards cubes à côté des sacs permet à l’estimateur de comparer un bon de béton prêt à l’emploi à une option bricolage en sacs sans qu’un tableur ne dérive entre le bureau et le chantier. Comme cette capacité est un moteur de parse pur, le prix de l’API est la base publiée de $0.002 par item réussi et la validation échouée ne consomme pas le solde.