help-octave
[Top][All Lists]
Advanced

[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
-------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]