Slashdot Mirror

Curiously, the Red hat dev did not comment on average case performance improvement, only on the slow path improvement. I initially missed that in a quick reading, as, I suspect, did many others.

It is difficult to compute impact of this work on the average case because we don't know precisely how many of the inputs in the entire domain (i.e. all unique FP representations in an IEEE754 double) are serviced by the slow path. I wasn't able to get the libm code to go down the mp path for the log function after a week of throwing different inputs at it. pow on the other hand hit it fairly regularly in an hour. Even the 'fairly regular' is about 1 in a 1000 inputs, so that is not much. We know that it is low enough that not a lot of people have complained about it, just some (and not all) math intensive applications. Perhaps a study similar to the worst cases paper I cited (the link is wrong btw, I'm working on getting that fixed) will give a better idea.

The other reason is that the slow path is literally thousands of times slower, so the impact it will have on the average case will depend greatly on the kinds of inputs an application uses. So in that context, talking about an average case with an arbitrary percentage of slow inputs (say 1%) would be cheating because it may show incorrectly large improvements.

Finally, the point of my post was more about sharing the methods I used for improvements than the statistics. I am personally not satisfied with the statistics because there is a lot more that can be done.

PS: I am the Red Hat dev who wrote the post (if it wasn't obvious) and the correct link to the paper is: http://perso.ens-lyon.fr/jean-...

Mathematica in particular uses adaptive precision; if you ask it to compute some quantity to fifty decimal places, it will do so.

In general, if you want bit-for-bit reproducible calculations to arbitrary precision, the MPFR library may be right for you. It computes correctly-rounded special functions to arbitrary accuracy. If you write a program that calls MPFR routines, then even if your own approximations are not correctly-rounded, they will at least be reproducible.

If you want to do your calculations to machine precision, you can probably rely on C to behave reproducibly if you do two things: use a compiler flag like -mpc64 on GCC to force the elementary floating point operations (addition, subtraction, multiplication, division, and square root) to behave predictably, and use a correctly-rounded floating point library like crlibm (Sun also released a version of this at one point) to make the transcendental functions behave predictably.

Prototypes of a modern calculator could be coded in Java-Script or Dart and presented
on a browser.

I seriously question whether JavaScript's internal number representation would be accurate enough to implement a calculator for use in education. All numbers in JavaScript are represented as double-precision floats, which IMHO are not going to be accurate enough ......

Nothing prevents a string oriented math lib!
This is a calculator not a machine for HPC. So yes your point is valid
with the point that precision is a topic to discuss and teach.

http://en.wikipedia.org/wiki/Dc_(computer_program)
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=100
1/3 .3333333333333333333333333333333333333333333333333333333333333333333\
333333333333333333333333333333333

So for each N 3 4 6 7 9 20 50 100 500 1000 whatever
do
scale=N
"run function"
done

IMO 64bit IEEE floating point is marginal. With modern transistor counts
we should be looking at Alpha's 128 and even 256 bit native floating point hardware support.

The most interesting bit is the fragile nature of transcendental functions and friends. ...
see: http://lipforge.ens-lyon.fr/www/crlibm/documentation.html

Oh and stupid user tricks that "PI=3.14" in the front of a dusty FORTRAN deck used for Gulf of Mexico
circulation dynamic modeling that was also used to support some global warming stuff.

Wise up, people. That's not a telescope, it's a wave motion gun. Just compare to its predecessor, Space Telescope Yamato - although the main weapon has been moved from a spinal mount to a giant deck emplacement, they're using the same hull layout and even an identical color scheme.

You forgot the reference...

http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf :-)

Agreed. Chapter 9 of Zen and the Art of Motorcycle Maintenance talks about that in more detail.

Mary Tsingou is an example of a woman who should have been famous for her programming, but she didn't get the credit for her work.

A pdf of the Physics Today article about her and what she did: http://perso.ens-lyon.fr/thierry.dauxois/PAPERS/pt61_55.2008.pdf

I know this is a joke, but let's say we somehow managed in some science fiction scenario to melt all the ice in Greenland and Antarctica.
http://m8y.org/images/world_noice.jpg
You'd end up with something like that.
You bought a bit too far inland. :)
Used this toy.
http://www.ens-lyon.fr/Planet-Terre/Infosciences/H istoire/Eustatisme/Applets/index.html

Debian is easy to install and update through the network. And there is a package replicator available to replicate an machine installation through the network. It's really great. The replicator maintainer is also very responsive. I had lots of mail exchange with him and he helped me if I needed. got to http://www.ens-lyon.fr/~schaumat/replicator/