On Thursday, 20 February 2014 at 23:52:13 UTC, Chris Williams
wrote:
I don't quite understand his ubox stuff, but his unum format
doesn't really solve the 0.1 problem, except maybe by allowing
the size of his values to exceed 64-bits so that precision
errors creap up a little bit slower. (I'm not sure how many
bits his format tops out at and I don't want to re-open the PDF
again to look).
Exctly. If I read correctly it should cover 128+ bits.
It also wasn't clear whether his format removed
the multiple values of NaN, -0, etc. It looked like it was just
the current IEEE formats bonded to a sliding bit-length
Pretty sure it would not. It seems to me that space wasted by
multiple representations is still there. The only real advantage
is that you can probably store a NaN in 8 bits. Honestly, who
cares. If I get a NaN in my numerical simulation, I have bigger
concerns other than saving memory space.
I think the only way to solve for problems like 0.1 in decimal
not mapping to any reasonable value in binary is to store
numbers as integer equations (i.e. 0.1 = 1/10), which would
take a hell of a complex format to represent and some pretty
fancy CPUs.
In fact, true rational numbers can only be represented by
rational numbers. How extraordinary! :P
The whole idea has one merit: the float now stores it's own
accuracy. But I think you can achieve more or less the same goal
by storing a pair of something. The whole idea of saving space
sounds bogus, at least for my field of application. We already
have an amazing technique for saving a lot of space for numerical
simulation of PDEs, it's called grid refinement.
