You are reading content from Scuttlebutt
@aljoscha %LQo5KOMeR+aj+Ej0JVg3qLRqr+wiKo74nS8Uz7o0LDM=.sha256

Fun problem of the day: What is the maximum value for JSON.stringify(some_valid_float).length?

Here is what I know so far: It is at least 25, since the rust float formatting implementation for ssb messages overflows a 24 byte buffer. The float in question is -0.0000015809161985788154. In the ssb float formatting spec, this is the case where -6 < n <= 0, and n is in fact minimal (-5), so that gives me some hope that it never gets worse than this. The ryu rust crate works fine with 24 bytes, and it checks against -5 as a lower bound in that case (which indeed results in a string of length 24). So that's some strong evidence that length 25 is the worst case. But to know for sure, I need an upper bound on the value of k (see the link to the ssb spec for the definition).

Brute forcing is not an option. I guess it is back to the float printing papers.

I love this job.

@aljoscha %efQkXxpPu6yI21wUMGkcg3aD+0zCaBRCWYrfQRntXFQ=.sha256

Answer: k is at most 20 (since the implementation I use stores the mantissa as an unsigned 64 bit integer, and the length of the decimal representation of the largest one of those is 20.

Thus the maximum length is indeed 25. The other cases have lower bounds (and I don't expect anybody else to care about this at all, so i won't write about them...).

So by choosing to begin printing small numbers in scientific notation at 6 leading zeros rather than 5, the ECMAScript team made it necessary to use a buffer of 25 bytes rather than the much more natural 24 bytes =/

@aljoscha %xvRmFkM1O+3YzVLdJFT7Et4kTYf0IF8CJxiSHahrp2U=.sha256

Best commit ever!

Join Scuttlebutt now