Implement the "unum" representation in D ?

Chris Williams yoreanon-chrisw at yahoo.co.jp
Thu Feb 20 15:52:10 PST 2014


On Thursday, 20 February 2014 at 23:13:20 UTC, Francesco 
Cattoglio wrote:
> On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
>>
>> The abstract is here:  
>> http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
>
> "The pursuit of exascale floating point is ridiculous, since we 
> do not need to be making 10^18 sloppy rounding errors per 
> second; we need instead to get provable, valid results for the 
> first time, by turning the speed of parallel computers into 
> higher quality answers instead of more junk per second"
>
> Ok, I think I know a bunch of people who could question the 
> contents of that sentence. Or, at the very least, question this 
> guy's way of presenting sensational news.

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). 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, which would 
bring along with it all the problems of the IEEE format that he 
mentioned.

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.


More information about the Digitalmars-d mailing list