Random rounding errors

[Marco Caliari-4]

Hi all.

I have a very long script made of several functions which computes some
quantities (what else?). There is a main for-loop. When the length is
around (or below) 50, I can run and run the script and I always get
the same result (as expected, of course).
As soon as I start to increase the length of the loop, I can get different
(in the last few digits) results if I run the script more times (with
clear all in front). I said "I can", because it seems that some results are
preferred and they often occour. When the length of the for loop is around 500,
the results differ in the last 7-8 digits and it seems there are no preferred
results.
There is no random function in the script and this behaviour is
not present in Matlab. The script uses basic linear algebra functions
(provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
Octave 3.0.*, gcc (GCC) 4.1.3.
I would appreciate any hint on how to isolate the problem in order to
submit an useful bug report.

Thanks,

Marco
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 12-Mar-2008, Marco Caliari wrote:

| There is no random function in the script and this behaviour is
| not present in Matlab. The script uses basic linear algebra functions
| (provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
| Octave 3.0.*, gcc (GCC) 4.1.3.
| I would appreciate any hint on how to isolate the problem in order to
| submit an useful bug report.

Have you tried using another version of ATLAS like the reference
LAPACK and BLAS libraries?  Do they also show the same behavior on
your system?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[dbateman]

John W. Eaton wrote:

On 12-Mar-2008, Marco Caliari wrote:

| There is no random function in the script and this behaviour is
| not present in Matlab. The script uses basic linear algebra functions
| (provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
| Octave 3.0.*, gcc (GCC) 4.1.3.
| I would appreciate any hint on how to isolate the problem in order to
| submit an useful bug report.

Have you tried using another version of ATLAS like the reference
LAPACK and BLAS libraries?  Do they also show the same behavior on
your system?

Or its an issue with the register length on the x86 platform and the "-ffloat-store" option would fix it. That probably wouldn't be fixed by a change in blas/lapack if they were both compiled with the same flags.

D.

[Marco Caliari-4]

> | There is no random function in the script and this behaviour is
> | not present in Matlab. The script uses basic linear algebra functions
> | (provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
> | Octave 3.0.*, gcc (GCC) 4.1.3.
> | I would appreciate any hint on how to isolate the problem in order to
> | submit an useful bug report.
>
> Have you tried using another version of ATLAS like the reference
> LAPACK and BLAS libraries?  Do they also show the same behavior on
> your system?

No. With the reference blas and lapack, everything is fine with Octave
3.0.0 (by the way, I had some problems trying to compile the Mercurial
archive of March 5: compilation and installation went fine, but then the
sort function required liblapack_atlas.so.3 which was no more on the
system).
I tried the code on another machine with Octave 3.0.0 and AMD ACML 3.6.0:
no problem. So, the atlas libraries seem to be the problem.
David, I didn't understand: could the flag -ffloat-store be the
problem or the fix? How can I verify if this is the problem?

Thanks,

Marco
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Marco Caliari wrote:
> David, I didn't understand: could the flag -ffloat-store be the
> problem or the fix? How can I verify if this is the problem?
>
>  
Using -ffloat-store to compile the atlas/blas/lapack might be the
solution.. The x86 registers are longer than the double precision
numbers they represent. That is a multiplication of two 64 bit double
precision numbers results in a value store in an 80 bit register. The
following calculation can use this 80 bit value directly, rather than
having to reload the value in to the register first, resulting in
slightly higher precision and faster calculations. The sense of the
"-ffloat-store" flag is that all register values are stored to memory
after a calculation forgoing this optimization.

It most cases you don't want to use "-ffloat-store", but I think this
reuse of the register values might be the cause of the randomness in
your solutions. What I believe is happening is that the kernel is
preempting the process, forcing the calculation back to memory and
loosing those extra 16bits of precision. When this occurs will appear
entirely random as its up to the kernel to decide when to preempt the
calculation. For same calculations (and certainly those that take less
than 10ms) it is hardly preempting your calculation, but when the
calculation becomes large it might. The predominant value of the
solution you are seeing is probably the one where the calculation is not
preempted.

I'm surprised you don't see similar behavior for reference blas though I
suspect it might be that atlas makes more use of this optimization than
the reference blas.. In any case compiling atlas/lapack/blas with
-ffloat-store should probably address the issue. However, if the above
is the cause of the issue, then perhaps you really shouldn't care.....

Regards
David

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 13-Mar-2008, Marco Caliari wrote:

| > | There is no random function in the script and this behaviour is
| > | not present in Matlab. The script uses basic linear algebra functions
| > | (provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
| > | Octave 3.0.*, gcc (GCC) 4.1.3.
| > | I would appreciate any hint on how to isolate the problem in order to
| > | submit an useful bug report.
| >
| > Have you tried using another version of ATLAS like the reference
| > LAPACK and BLAS libraries?  Do they also show the same behavior on
| > your system?
|
| No. With the reference blas and lapack, everything is fine with Octave
| 3.0.0 (by the way, I had some problems trying to compile the Mercurial
| archive of March 5: compilation and installation went fine, but then the
| sort function required liblapack_atlas.so.3 which was no more on the
| system).
| I tried the code on another machine with Octave 3.0.0 and AMD ACML 3.6.0:
| no problem. So, the atlas libraries seem to be the problem.
| David, I didn't understand: could the flag -ffloat-store be the
| problem or the fix? How can I verify if this is the problem?

Does the packaged Octave also work properly if you use the atlas3-base
package instead of the sse2 version?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Marco Caliari-4]

> On 13-Mar-2008, Marco Caliari wrote:
>
> | > | There is no random function in the script and this behaviour is
> | > | not present in Matlab. The script uses basic linear algebra functions
> | > | (provided by atlas3-sse2_3.6.0-20.6_i386.deb). The problem is present in
> | > | Octave 3.0.*, gcc (GCC) 4.1.3.
> | > | I would appreciate any hint on how to isolate the problem in order to
> | > | submit an useful bug report.
> | >
> | > Have you tried using another version of ATLAS like the reference
> | > LAPACK and BLAS libraries?  Do they also show the same behavior on
> | > your system?
> |
> | No. With the reference blas and lapack, everything is fine with Octave
> | 3.0.0 (by the way, I had some problems trying to compile the Mercurial
> | archive of March 5: compilation and installation went fine, but then the
> | sort function required liblapack_atlas.so.3 which was no more on the
> | system).
> | I tried the code on another machine with Octave 3.0.0 and AMD ACML 3.6.0:
> | no problem. So, the atlas libraries seem to be the problem.
> | David, I didn't understand: could the flag -ffloat-store be the
> | problem or the fix? How can I verify if this is the problem?
>
> Does the packaged Octave also work properly if you use the atlas3-base
> package instead of the sse2 version?

Octave 3.0.0 with atlas3-base has the same problem I described above.

Marco
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave