News for hackers. Stuff that matters.
Re:Formatting floating point numbers by TorKlingberg on Friday June 14, 2019 @07:55AM (#20182214)
The "obsession" came about from all the problems with binary formats. Byte ordering. Unspecified signedness. Memcpy:ing structs with padding. Programmers micro-optimizing by choosing the smallest possible field size, and then you can't change it when it turns out to be too small. Format specs using WORD as if that's a well-defined size. Using int, long, etc, and assuming they are the same size everywhere.

It's a trade-off of CPU usage versus flexibility. It's not surprising that textual serialization formats took off together with managed memory languages.

Re:Formatting floating point numbers by IshKebab on Friday June 14, 2019 @12:23PM (#20184220)
Rubbish. It's possible to have poorly defined text formats just as easily as binary formats. Remind me how to read CSV again? How do I store 64-bit integers in JSON?

Text formats are popular because you don't have to use a special tool to view them. That's the only reason.

Re:Formatting floating point numbers by cbsmith on Friday June 14, 2019 @07:36PM (#20187531)
> Text formats are popular because you don't have to use a special tool to view them. That's the only reason.

But you need a special tool to get a computer to read them. Seems like not a win. Throw in compression & encryption... and suddenly you need a special tool anyway.

Re:Formatting floating point numbers by datenwolf on Friday June 14, 2019 @09:34AM (#20182809)
Byte ordering issues are easily addressed by still emitting text, but not converting to a base that differs in a prime factor. Just emit the mantissa and exponent in – say – hexadecimal form and the negative sign bit as a `-`. It avoids all the endianes issues and is trivially converted.
Re:Formatting floating point numbers by cbsmith on Friday June 14, 2019 @07:33PM (#20187520)
Fortunately with text you can't have issues with byte ordering, unspecified signedness, or padding... oh wait. ;-)