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: <email@example.com> <firstname.lastname@example.org> <email@example.com> <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
I imagine it is. But more at the level of a puzzlement rather than an
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