Re: Re: Non-deterministic numerical inaccuracies in
- To: mathgroup at smc.vnet.net
- Subject: [mg95727] Re: [mg95698] Re: Non-deterministic numerical inaccuracies in
- From: danl at wolfram.com
- Date: Sun, 25 Jan 2009 21:48:40 -0500 (EST)
- References: <gjcuio$cnf$1@smc.vnet.net> <gjkvd4$92g$1@smc.vnet.net>
> Daniel Lichtblau wrote: >>> >>> The bad news is that it is a consequence of the M.K.L. which can't >>> be avoided. The good news is that you should not care about it. >>> If the difference seems important then you are doing something >>> wrong. First I should point out that the above remark was not mine. It was in a note I had at least in part quoted. That said, I neither fully agree nor disagree with it. If small machine arithmetic fuzz is bedeviling your code, you almost certainly are doing something a bit unsafe. > I think we should care about it! Lots of programs have different > behaviours depending on a real number threshold, and this behaviour > means that there is the possibility of a test flipping different ways on > different runs of a program! One has to be careful about choosing the threshold, etc. A few bits for BLAS machine arithmetic tolerance seems not unreasonable to me. > This could be a debugging nightmare, and will be in the back of people's > minds whenever anything 'strange' happens. > > Would it not be possible to revert to the previous, slightly less > optimal, library until (presumably) the library is fixed? > > David Bailey > http://www.dbaileyconsultancy.co.uk My understranding is that the library vendors do not regard it as broken, so I am not optimistic that the library itself will change. We have made some effort to align machine floats to 16 bits so this particular behavior should stabilize in a future release. I am not really competent to discuss the issues involved in going to a different library. Maybe others can address that. I can only voice my suspicion that it would be difficult, and offer dubious gain. Daniel Lichtblau Wolfram Research