- 52comments
- 2comments
- 1comments
- 19comments
- 200comments
- 95comments
- 109comments
- 2comments
- 15comments
- 408comments
- —discuss
- —discuss
- 72comments
- 69comments
- 132comments
- 13comments
- 26comments
- 9comments
- 49comments
- 114comments
- 881comments
- 29comments
- 8comments
- 23comments
- 301comments
- 103comments
- 274comments
- 396comments
- 86comments
- 25comments
Are logarithmic number systems a better alternative to floats?
Sometimes. :) They are faster to multiply, divide, exponentiate, and take roots of. But they are a lot harder to add and subtract, and of course it is somewhat less accurate.
"Grisu3 works on 99.49% of random IEEE doubles."
What a curious benchmark! It makes you wonder all kinds of things like how many IEEE doubles there are; how you sample from them randomly; what kind of coverage of the reals you get; and how relevant it all is.
IEEE doubles are just 64-bit words; so there are 2^64 and you sample randomly by picking a random 64-bit word.
(There are some subtleties: a "random 64-bit word interpreted as a double" is clearly not uniformly distributed over the reals; x86/amd64 uses 80-bit doubles for intermediate results, except when it doesn't; there are things like subnormals ("really small numbers"), Not-a-Number, Infinity, -Infinity, -0; but the above should give you the right general idea)
Sure, but to take an extreme example, suppose you have a division operator that fails to check for division-by-zero. Then your operator works in 100 * (1 - 2^63)% of all cases. That gives you 18 nines and sounds pretty convincing but it's hardly the point.
In the same way I'm wondering how meaningful it is to say that an algorithm works for 99.49% of all doubles, sampled uniformly. In other words, how could I use that benchmark to make a judgement about using grisu3?
Keeping everything in rational form would be nice, and easy to present.
Let's start with Pi.
I'm sure you mean Tau.
355/113 is good enough for Chuck Moore (the Forth guy).
http://www.colorforth.com/pi.htm
[edited to correct blatant error. Thanks Florin]
You mean 355/113
Spot on!
Either that or pi is a symbol and we use symbolic algebra. Just convert to the result in floating point at the last minute.
Ironically my calculator quite happily manages rational form including PI as a constant:
http://h41111.www4.hp.com/calculators/uk/en/scientific/smart...
Needs lazy evaluation. Just don't try to look at the whole number at once.
Here you go: http://crd.lbl.gov/~dhbailey/pi/pi-alg Now you can calculate any individual digit of pi without having to find any of the others! Unfortunately, it only works in base 16 or base 2, not base 10.
http://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93...
http://mathworld.wolfram.com/BBP-TypeFormula.html
Link appears to be down. No joy with Google or Corel cache. Google search turned up a PDF at http://0-dl.acm.org.millennium.lib.cyut.edu.tw/ft_gateway.cf...
http://webcache.googleusercontent.com/search?aq=f&source... worked for me, but it appears to be completely back up now
the Grisu family acts as the default rendering algorithms in both the V8 and Mozilla Javascript engines (replacing David Gay's 17-year-old dtoa code)
Hmm. I think maybe a weekend hack is in order. Perhaps dtoa in Python can be replaced in a similar fashion, since Python maintains David Gay's algorithm as an upstream source.
http://hg.python.org/cpython/file/fc831c49216d/Python/dtoa.c
EDIT: Looks like there has already been some gripes about the quality of David Gay's implementation.
http://bugs.python.org/issue9009