Calculateur de mortier

Vous gardez un seul système d'unités de bout en bout—mètres cubes avec mètres cubes, ou pieds cubes avec pieds cubes—et remplacez éventuellement bag_volume lorsque votre fournisseur indique une couverture différente de la valeur par défaut. La même fonction pure alimente l'outil gratuit du navigateur et l'API payante, de sorte qu'un devis téléphonique coïncide avec la ligne qu'un script publie ensuite. Un nombre d'unités négatif est rejeté avec un message invalid_input clair au lieu d'un volume absurde silencieux.

Comment le volume de mortier et le nombre de sacs sont calculés

Partez de l'identité d'estimateur utilisée sur de nombreux calculateurs de mortier du commerce et du négoce : le volume total de mortier égale le nombre de briques ou de blocs multiplié par le volume de mortier requis par unité, la figure par unité et le rendement du sac étant exprimés dans le même système d'unités cubes. Le volume par unité n'est pas inventé : il vient de votre conception de joint, de la taille de brique et de la pratique—souvent près de zéro point zéro zéro zéro huit à zéro point zéro zéro un deux mètres cubes par brique d'argile standard avec joints typiques de dix millimètres, ou une figure différente avec blocs de béton, systèmes à lit mince ou joints épais de mur de jardin. Écrivez mortar_volume égale units fois mortar_per_unit. L'estimation de sacs divise ce volume total par bag_volume, le rendement cubique imprimé ou implicite sur le produit (par exemple environ zéro point zéro un deux mètres cubes pour un mélange de mortier en sac typique, ou environ zéro point quatre pieds cubes pour un sac courant en pratique impériale). bags_exact est le quotient réel ; bags est le plafond de ce quotient car les magasins vendent des sacs entiers, pas des fractions. spare_volume est le rendement supplémentaire que le nombre de sacs arrondi couvre au-delà du volume de mortier nu, utile lorsque vous voulez un petit coussin de surplus sans inventer un champ de pourcentage de déchets séparé. Lorsque bag_volume est omis le calculateur utilise la valeur par défaut documentée de zéro point zéro un deux unités cubes et met 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 horodatages d'horloge murale et sans appels réseau, donc des entrées identiques produisent toujours le même JSON. Le nombre d'unités ne doit pas être négatif : un nombre négatif de briques ou de blocs est rejeté avec invalid_input car une quantité négative est non physique. Zéro unités est autorisé et donne zéro mortier et zéro sacs. mortar_per_unit doit être non négatif, et bag_volume, lorsqu'il est fourni, doit être strictement positif pour que le ratio soit défini.

Ce que vous envoyez et ce que vous recevez

Lorsque units est négatif la requête échoue avec un message indiquant que le nombre d'unités ne peut pas être négatif, pour que les clients corrigent le nombre avant de réessayer au lieu de recevoir un volume négatif. Envoyez deux nombres finis obligatoires : units pour le nombre de briques ou de blocs, et mortar_per_unit pour le volume de mortier requis par brique ou bloc dans des unités cubes concordantes. Envoyez éventuellement bag_volume comme le rendement cubique d'un sac de mélange dans des unités cubes concordantes ; si vous l'omettez la valeur par défaut zéro point zéro un deux s'applique. Champs obligatoires manquants, chaînes non numériques, NaN et Infinity échouent avec invalid_input et ne sont pas facturés. En succès la réponse renvoie les entrées nettoyées, mortar_volume, le bag_volume utilisé et s'il était par défaut, bags_exact, bags entiers, spare_volume, un unit_note rappelant de garder un système d'unités, et une courte chaîne de formule pour la documentation. Vérifications classiques : cinq cents unités à zéro point zéro zéro un mètres cubes chacune avec bag_volume par défaut : le volume de mortier est zéro point cinq mètres cubes, bags_exact est environ quarante et un point six sept, et bags plafonne à quarante-deux. Une autre vérification utile est mille deux cents blocs à zéro point zéro zéro deux avec bag_volume zéro point zéro deux : le volume de mortier est deux point quatre et bags plafonne au sac entier suivant. Le prix des appels API réussis est la base publiée de $0.002 par élément ; les échecs de validation ne consomment pas le solde prépayé.

Où les calculateurs de mortier interviennent en pratique

Les propriétaires qui construisent un mur de jardin, une jardinière ou un placage ont besoin d'un décompte de sacs fiable avant d'aller en magasin de matériaux, surtout lorsque les grands sacs de mélange sont lourds et difficiles à retourner une fois ouverts. Les fournisseurs impriment souvent la couverture du sac en mètres carrés de mur ou en rendement cubique ; convertir un décompte de métré via le volume de mortier par unité rend cette comparaison transparente plutôt qu'une règle empirique boîte noire. Si vous avez ensuite besoin de surface de mur à partir de longueur et hauteur, d'épaisseur de joint à partir des dimensions de face de brique, de sélection de type de mortier par grade de résistance, ou de volume de dalle de béton pour semelles sous le mur, traitez-les comme intentions de recherche et pages distinctes plutôt que de surcharger cette page calculateur de volume de mortier et sacs par brique et bloc. Les équipes de maçonnerie et d'aménagement paysager construisent des plannings d'achat à partir des décomptes de briques et blocs du métré et des rendements de joint de conception ; un seul endpoint déterministe qui plafonne les sacs réduit la dérive de tableur entre l'estimateur et l'acheteur. Les gestionnaires immobiliers planifiant plusieurs tronçons de cloison ou d'aménagement alimentent chaque paire nombre d'unités et mortar_per_unit via l'API et joignent bags aux bons de commande pour que le surstock soit intentionnel. Comme cette capacité est un moteur de parse pur, le prix API est la base publiée de $0.002 par élément réussi et l'échec de validation ne consomme pas le solde.