Any thoughts on this? A new format for handling numbers, different to IEEE floating point. The headline seems hyperbole to me, and I haven't finished reading the article yet, but so far I can't see support for the claim. Some things seem an odd approach to me too (a bit for exact / inexact - great, but what do you do with that knowledge?) However, I am by no means an expert in this area, and if it's published by the ACM better minds than mine must have examined it.
Any thoughts on this? A new format for handling numbers, different to IEEE floating point. The headline seems hyperbole to me, and I haven't finished reading the article yet, but so far I can't see support for the claim. Some things seem an odd approach to me too (a bit for exact / inexact - great, but what do you do with that knowledge?) However, I am by no means an expert in this area, and if it's published by the ACM better minds than mine must have examined it.
http://ubiquity.acm.org/article.cfm?id=2913029
http://ubiquity.acm.org/article.cfm?id=2913029
http://ubiquity.acm.org/article.cfm?id=2913029
http://ubiquity.acm.org/article.cfm?id=2913029
Eric Grange If you know your problem will only deal with "nice" angles, then you could have exact representations of 1/2 \sqrt(2) and 1/2 sqrt(3), along with the \pi ones, and keep the numbers exact, including for the inverse (arccos).
ReplyDeleteOf course in the general case that won't help much, no disagreement there.
But the posibility to have control over which values you want to be able to represent exacly along with control over the precision vs range tradeoff seems to me to be quite interesting and potentially very useful.
David Millington One thing is registers, going 128bit fixed point would increase ucompressed storage by 4x (as in, memory consumption). And you'd still "only" have 38 orders of magnitude range, which may be insufficient for intermediate calculations.
ReplyDeleteDavid Millington Again a concrete example from the renderer. It has several areas where we need to a * b * c * d, which are later divided by x * y * z * w. Each of the factors involved may be on the order of 1e6, so the result comes out as close to unit.
ReplyDeleteHowever the intermediate values are on the order of 1e24 and would require around 80 bits, overflowing the 63 bits available from your proposed fixed point format (assuming 1 bit for sign).