4 ms·
“Something in the middle” could be an option. E. g. (in C) > printf ("%a\n", M_PI); 0x1.921fb54442d18p+1 > printf ("%a\n", 42.0); 0x1.5p+5
by lelf 7y ago
“Something in the middle” could be an option. E. g. (in C)
> printf ("%a\n", M_PI);
0x1.921fb54442d18p+1
> printf ("%a\n", 42.0);
0x1.5p+5
- 0815test 7y agoThis should be a lot higher. Hexfloats are not just a C/C++ thing, plenty of languages and software packages support them by now. And they can very much be used as part of a text input format, to avoid the sizeable overhead of "human-friendly" float parsing. If you maintain a text-based format that has any chance of being a CPU/compute bottleneck in this way, you should definitely make sure that hexfloats are supported! Edit: someone else mentioned that roundtrip accuracy could also be an issue. Theoretically true, I guess, but really, if you want to use decimal-based float input you should just use an algorithm that roundtrips correctly, and eat that overhead. Anything else has a potential to impact reproducibility of results, etc. It's not worth it silently corrupting your data just for that saving in compute cost.
- brandmeyer 7y agoHear, hear! Sometimes you do need to reliably communicate a floating-point number across a text channel. Hex float is low-risk in the sense that both the encoding and decoding process are much simpler and therefore easier to verify than something that round-trips through decimal. Yes, there are some correct implementations of the decimal<->binary algorithms that round-trip correctly. But there also remain a number of incorrect implementations.
- cbsmith 7y agoTo be clear: human readable formats when you have humans reading the data makes sense. What is insane is having machines reading & writing human readable formats to talk to each other.