Escalador de porciones de receta

Las raciones o cantidades no positivas, las listas vacías y los valores no finitos se rechazan con invalid_input, de modo que un dato erróneo nunca produzca un lote silencioso a cero. El camino es aritmética pura y determinista—sin red, sin semillas aleatorias, sin dependencia del reloj—así que el ejecutor gratuito del navegador y la API de prepago devuelven el mismo JSON tras un redondeo decimal fijo cada vez que la invoque.

Cómo llamar a la API: campos, validación y forma de la respuesta

Cada amount debe ser asimismo positivo y finito; una lista vacía se rechaza porque no hay nada que escalar. Prefiera poner las unidades en el campo opcional names en lugar de dentro de las cadenas de amount, para que doscientos cincuenta y la harina en gramos queden separados y el solver no tenga que analizar texto mixto. Envíe un cuerpo JSON con amounts como array obligatorio de números finitos positivos—o una cadena separada por comas en formularios de texto—más original_servings y target_servings (los alias incluyen servings, from_servings, original para el conteo de origen, y target, to_servings, new_servings para el de destino). Ambos conteos de raciones deben ser números finitos estrictamente positivos; cero, negativos, ausentes o no numéricos devuelven invalid_input y no se cobran. Los valores absolutos se mantienen dentro del límite publicado de un billón, y la longitud de la lista está acotada para que un Worker termine con rapidez. En éxito la respuesta devuelve amounts redondeados, scaled, scale_factor, original_servings, target_servings, count, names opcionales, filas de ingredients que emparejan cada cantidad original con su valor escalado, formula, message y steps ordenados para auditorías. La validación fallida—amounts vacíos, números no finitos, raciones o cantidades no positivas, o campos obligatorios ausentes—devuelve invalid_input con un mensaje que nombra el problema. El precio es un fijo de $0.002 por solicitud correcta con unit item y precio unitario marginal cero.

Consejos prácticos, errores frecuentes, límites y herramientas relacionadas

Al escalar para invitados, compruebe que cada línea de la ficha sea proporcional—algunas recetas dejan el sazonado al gusto o fijan el tamaño de la sartén, así que puede escalar los ingredientes a granel y dejar las pizcas de especia a criterio. Esta landing se dirige a quienes buscan un escalador de porciones de receta, escalar ingredientes por raciones o una calculadora de rendimiento de lote; no es un convertidor de unidades, ni un estimador nutricional, ni un planificador de comidas completo. Prefiera herramientas hermanas de cocina o conversión cuando necesite tazas de harina a gramos o cucharadas a mililitros, y luego escale aquí los números resultantes. Las comprobaciones de ida y vuelta son sencillas: recalcule a mano cada amount por el factor y confirme que coincide con la entrada scaled publicada con el mismo redondeo a doce decimales, y confirme que al cambiar solo el objetivo se escala cada línea de forma proporcional dejando las etiquetas alineadas. Mantenga siempre original_servings distinto de cero y positivo en los formularios del cliente antes de enviar; la API seguirá lanzando un invalid_input claro si se cuela un cero o un conteo negativo, porque dividir por cero o inventar un lote negativo no es un escalado con sentido. Prefiera números en lugar de cadenas de unidad ya formateadas dentro de amounts; ponga las unidades en el campo opcional names. Los valores flotantes cercanos al límite se redondean a doce decimales para una comparación JSON estable entre motores. Las tareas fallidas que devuelven invalid_input no consumen saldo prepago, lo que mantiene baratos los scripts exploratorios cuando los aprendices envían a propósito raciones cero o listas vacías. En catering, convierta un lote piloto de ocho platos en un servicio de cuarenta y ocho enviando original_servings ocho y target_servings cuarenta y ocho, de modo que el factor se derive automáticamente sin un campo multiplicador aparte.