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