Inconsistent quantity display: lossy fraction approximation (1 5/8 cup shown as 1 2/3 c) and no control over unit conversion

[dubadub]

Summary

A user report from the community: fractional quantities are displayed inconsistently between the web UI and the terminal, the terminal's fraction rendering is lossy (shows a different number than what was written), and quantities are silently converted to a different unit ("best unit") with no way to opt out.

I created a test recipe with @milk{1 5/8%cup}. In the web UI, this ingredient is displayed as 1.625 c, which is correct; however, for measuring purposes I would prefer it shown as 1 5/8 cups. When displaying the same ingredient in the terminal with the cook recipe command, I get 1 2/3 c which is the format I prefer (although cups would be better than just c); however, it is the wrong number. I tried @cocoa{5/8%cup} as another ingredient. This is displayed as 10 tbsp in both the web UI and the terminal, which is not my preferred units. Are there settings to control when and how units are displayed or converted?

Reproduction

units-test.cook:

@milk{1 5/8%cup}
@cocoa{5/8%cup}

$ cook recipe units-test.cook

Ingredients:
  cocoa      10 tbsp
  milk       1 2/3 c

Reproduced on current main (post-0.33.1).

Problems

1. Lossy fraction approximation in the terminal. 1 5/8 (1.625) is rendered as 1 2/3 (~1.667) — a ~2.6% error presented with no indication it's approximate. The fraction display only considers halves, thirds, and quarters, so eighths (very common in US kitchen measures) get snapped to the nearest third. For measuring purposes this is actively misleading; 1 5/8 is exactly representable.
2. Web UI and terminal disagree. The web UI shows the raw decimal (1.625 c), the terminal shows an approximated fraction (1 2/3 c). Same recipe, two different numbers.
3. Silent "best unit" conversion. 5/8 cup becomes 10 tbsp in both UIs. The conversion is exact, but the user wrote cups and there is no setting to keep the unit as authored.
4. No display/conversion settings. There's currently no way to control fraction vs. decimal rendering, unit abbreviation (c vs cups), or whether unit conversion happens at all.

Notes on where this comes from

• The terminal ingredient list goes through group_ingredients(converter) (src/util/cooklang_to_human.rs), which fits quantities to a "best unit" — that's the 5/8 cup → 10 tbsp step — and then renders via the cooklang-rs quantity Display, which applies the lossy fraction approximation. The fraction/approximation behavior itself lives in cooklang-rs, so part of the fix may be upstream (allowing eighths/sixteenths for imperial volume units, or exposing the fraction config).
• The web UI renders the raw scaled value, hence the decimal.

Possible directions

• At minimum, never show an approximated fraction as if it were exact (either show the exact fraction when one exists — 1 5/8 does — or fall back to decimal, or mark approximations with ~).
• Align web UI and terminal rendering so the same recipe shows the same numbers.
• Add user-facing settings (CLI flags and/or config) for: keep-authored-units vs. best-unit conversion, fraction vs. decimal display, and full unit names vs. abbreviations.

[dubadub]

Root cause found: cookcli itself enabled the cooklang bundled_units feature in Cargo.toml (no dependency leaks it — cooklang-reports and cooklang-language-server both use default-features = false). That feature loads the unit database into Converter::default(), which drives both the silent best-unit conversion (5/8 cup → 10 tbsp) and the lossy fraction approximation (1 5/8 → 1 2/3).

#433 disables the feature: quantities now display exactly as authored (1.625 cup, 0.625 cup) in every output format, and the terminal and web UI agree.

Remaining open here: an opt-in way to render exact fractions (1 5/8 cups) and, longer term, user-controlled unit conversion settings.