[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Machine epsilon, Octave and Matlab
From: |
Thomas Shores |
Subject: |
Re: Machine epsilon, Octave and Matlab |
Date: |
Thu, 30 Aug 2001 10:02:52 -0500 |
Christoph Spiel wrote:
> On Wed, Aug 29, 2001 at 05:00:08PM -0500, Thomas Shores wrote:
> > Craig Stoudt wrote:
> > > Interesting. I'm running Octave 2.1.31 under Win2000.
> > > Running your script I get:
> > >
> > > x2 = 1.1102230246251565404e-16
> > > y2 = 0
> > > x4 = 5.5511151231257827021e-17
> > > y4 = 0
> >
> > Running Octave 2.1.34 under RedHat Linux 7.0 I get the same results
> > as Craig. I think the difference might be really a compiler issue.
>
> In fact it is NOT a compiler issue, but the code a compiler generates
> can trigger the problem.
>
> > --- snip ---
>
> > So what's the problem? Well, *if* the compiler is smart enough to
>
> It is not the compiler that evaluates the expression, but Octave,
> i.e., the interpreter.
>
> > take a compound expression like the one above and store intermediate
> > results in the Pentium FPU registers, the answer should come out OK.
>
> The interpreter tends to access (user) variables in memory, hence
> octave:1> 1 + eps/2 + eps/2 == 1
> ans = 1
> but calling a compiled function can hoist the same variables into
> the FPU registers and
> sum([1, eps/2, eps/2]) == 1
> might return false (it does for some interpreters I know of) if the
> FPU uses larger internal precision.
>
> > I'm guessing that for whatever reason this doesn't happen on the
> > Pentium, but does happen on the SGI compiler. Perhaps its a
> > question of optimization on one compiler and not on the other.
>
> The reasons are:
> (a) The Intel FPUs can use a wider internal data format.
> (b) The internal format can be controlled during runtime (of the
> application).
>
Christoph is right and I stand corrected: it is the interpreter that must
either store intermediate results in the FPU or store the wider format of
the numbers. As both he and I observed, it is *possible* for the Pentium
FPU to give accurate results for the stated problem, which allows for the
possibility that Matlab and Octave give different results on the same
calculation. One thing is still puzzling me, though. Why did the SGI
get better results than the Pentium system using the same version
(2.1.34) of Octave. Were they compiled differently?
Thomas Shores
-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.octave.org
How to fund new projects: http://www.octave.org/funding.html
Subscription information: http://www.octave.org/archive.html
-------------------------------------------------------------
- Machine epsilon, Octave and Matlab, Craig Stoudt, 2001/08/29
- Re: Machine epsilon, Octave and Matlab, geraint . p . bevan . itar, 2001/08/29
- Re: Machine epsilon, Octave and Matlab, Craig Stoudt, 2001/08/29
- Re: Machine epsilon, Octave and Matlab, geraint . p . bevan . itar, 2001/08/29
- Re: Machine epsilon, Octave and Matlab, Thomas Shores, 2001/08/29
- Re: Machine epsilon, Octave and Matlab, Christoph Spiel, 2001/08/30
- Re: Machine epsilon, Octave and Matlab,
Thomas Shores <=
- Re: Machine epsilon, Octave and Matlab, John W. Eaton, 2001/08/30
- Re: Machine epsilon, Octave and Matlab, Geraint Bevan, 2001/08/30
- Re: Machine epsilon, Octave and Matlab, John W. Eaton, 2001/08/30
- Re: Machine epsilon, Octave and Matlab, Alex Verstak, 2001/08/30