Joseph Ferano
b5e7351c7e
f64->bytes is snprintf "%g": six significant digits, exponent notation of its own accord, and no precision to pass it. A frame time of 1/60 comes back as 0.0166667 and a score past a million as 1.23457e+06. format-f64 returns a Vec instead, so it inherits neither that nor the shared static scratch buffer -- and it is the reason append-i64! exists, because it renders the integer part and the fraction through that one buffer in strict sequence. Half away from zero at the last digit kept, which is round-f32's rule and not printf's. 0.125 at two places is 0.13 here and 0.12 there; matching printf would mean pinning a particular libc's nearest-even on the binary value, and that answer is not the same on every target anyway. The three cases that ship broken are each one line and each tested: the carry, where the rounded fraction equals the scale and is the next integer (0.999995 at five places prints "0.100000" without it); the zero padding, without which 1.005 at three places prints "1.5"; and the sign, which belongs to the number rather than to its integer part, since -0.5 has an integer part of 0 and 0 carries no sign. The clamp on the precision is spelled (min 9 (max 0 prec)) and not with the clamp macro, and the reason is a finding: the prelude is never macro-expanded. macro.ml's pass runs over the file being compiled, and the prelude arrives at the checker through Check.program's own prepend, so a prelude function calling a prelude macro resolves the macro's underlying defn -- the one that takes a [Form] -- and reports an arity error.
