Re: Re: Non-deterministic numerical inaccuracies in
- To: mathgroup at smc.vnet.net
- Subject: [mg95814] Re: [mg95773] Re: Non-deterministic numerical inaccuracies in
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Wed, 28 Jan 2009 06:28:16 -0500 (EST)
- References: <gjcuio$cnf$1@smc.vnet.net> <gjkvd4$92g$1@smc.vnet.net> <glj89b$dj0$1@smc.vnet.net> <200901271156.GAA23062@smc.vnet.net>
David Bailey wrote: > danl at wolfram.com wrote: >>> Daniel Lichtblau wrote: > >> 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. >> >> > Surely aligning floats on 16-bytes would only be a partial fix because > if an array A were packed and 16-bytes aligned, A[2;;] would only be > 8-bytes aligned! That's true, or at least I should hope it is. But it will not matter in terms of getting reproducible results, because it will always go through the code that handles the non-16-byte-aligned case. The bad situation is when we create packed tensors on-the-fly inside Dot (as we repeat the same operation in a loop, say), and sometimes they are 16-byte-aligned and other times not. We made a change to have them always 16 byte aligned, so as to preclude this from happening in a future release. > It seems to me that it was a wretched decision of the C compiler writers > to plant code that delivers different results - however insignificant - > depending on data alignment! I wonder if anyone has reported to them > that this difference exists! Not that it matters too much, but I don't think this is the compiler writers' doing. It's in the BLAS library. I'm fairly certain they are aware of the discrepancy. > I was not suggesting using a different library - only a previous version > - such as that used inside 6.0.3, which was presumably compiled with an > earlier compiler. I would surmise there might be speed losses associated with this. But again, I'm just guessing. As for the software engineering aspect, it's probably not so hard since it's the same library. This assumes the API does not change in small ways between releases. I am not sure that this is a safe assumption. > The mere fact that several people have discovered this problem, suggests > to me that it will be an irritant. > > David Bailey > http://www.dbaileyconsultancy.co.uk I imagine it is. But more at the level of a puzzlement rather than an application killer. Daniel Lichtblau Wolfram Research
- References:
- Re: Non-deterministic numerical inaccuracies in
- From: David Bailey <dave@removedbailey.co.uk>
- Re: Non-deterministic numerical inaccuracies in