MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Partial derviatives in mathematica
  • Next by Date: Re: Real Solutions
  • Previous by thread: Re: Non-deterministic numerical inaccuracies in
  • Next by thread: Re: Combining Plots with Different Ordinate Axes in