Implement the "unum" representation in D ?

[Francesco Cattoglio]

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.