The C jets in lagoon.c and math.c return the IEEE result for overflow under directed rounding modes; the Hoon returns infinity. Under %z, %d (positive results) and %u (negative results), any exact result of magnitude at least 2^(emax+1) is inf in Hoon but the largest finite value in SoftFloat.
Repro on un-jetted Hoon (urbit eval on ++ff directly):
> `@ux`(~(mul ff [[8 23 --127] %z]) `@rs`0x7f7f.ffff .2)
0x7f80.0000 :: Hoon: +inf
> `@ux`(~(mul rs %z) `@rs`0x7f7f.ffff .2)
0x7f7f.ffff :: vere rs jet: MAX (IEEE-correct)
The same holds for add, sub, div, and every width; the cause is the mode-independent max-exponent check at the end of ++lug in ++fl. Root-cause issue filed on urbit/urbit: urbit/urbit#7426
Why it matters here.
- Every lagoon and math jet inherits this: under
%z/%d/%u the jet and the Hoon differ on overflowing inputs, so the C jets are not bit-exact against the Hoon today. The existing test suites do not hit it (overflow needs magnitude at least MAX + 1 ulp, and the tests stay well inside range).
- On NockApp,
NOCK_TEST_JETS runs jet and Nock side by side and bails on any mismatch, so a Rust lagoon jet with IEEE semantics would fail that mode until the Hoon is fixed.
Proposed handling. Keep the jets IEEE-correct (they already are) and fix ++fl upstream; the NockApp softfloat crate will implement IEEE saturation. Add directed-mode overflow cases (MAX * 2, MAX + MAX, -MAX * 2 under each of %z/%u/%d) to the lagoon and math test suites once the Hoon lands so the divergence cannot come back silently.
Related but harmless: _set_rounding_la and math.c map %a to softfloat_round_near_maxMag, while Hoon's %a in ++fl is directed round-away-from-zero (toi of 2.25 under %a is 3). No door admits %a (all are ?(%n %u %d %z)), so it is unreachable; worth a comment or removal.
The C jets in
lagoon.candmath.creturn the IEEE result for overflow under directed rounding modes; the Hoon returns infinity. Under%z,%d(positive results) and%u(negative results), any exact result of magnitude at least 2^(emax+1) isinfin Hoon but the largest finite value in SoftFloat.Repro on un-jetted Hoon (
urbit evalon++ffdirectly):The same holds for
add,sub,div, and every width; the cause is the mode-independent max-exponent check at the end of++lugin++fl. Root-cause issue filed on urbit/urbit: urbit/urbit#7426Why it matters here.
%z/%d/%uthe jet and the Hoon differ on overflowing inputs, so the C jets are not bit-exact against the Hoon today. The existing test suites do not hit it (overflow needs magnitude at least MAX + 1 ulp, and the tests stay well inside range).NOCK_TEST_JETSruns jet and Nock side by side and bails on any mismatch, so a Rust lagoon jet with IEEE semantics would fail that mode until the Hoon is fixed.Proposed handling. Keep the jets IEEE-correct (they already are) and fix
++flupstream; the NockAppsoftfloatcrate will implement IEEE saturation. Add directed-mode overflow cases (MAX * 2,MAX + MAX,-MAX * 2under each of%z/%u/%d) to the lagoon and math test suites once the Hoon lands so the divergence cannot come back silently.Related but harmless:
_set_rounding_laand math.c map%atosoftfloat_round_near_maxMag, while Hoon's%ain++flis directed round-away-from-zero (toiof 2.25 under%ais 3). No door admits%a(all are?(%n %u %d %z)), so it is unreachable; worth a comment or removal.