help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Same .m file: different results with different versions of Octave


From: Judd Storrs
Subject: Re: Same .m file: different results with different versions of Octave
Date: Sun, 18 Apr 2010 16:28:44 -0400

On Sun, Apr 18, 2010 at 3:28 PM, Jaroslav Hajek <address@hidden> wrote:
> Octave is a system for *numerical* computations. The results of its
> computations are, in general, approximations. The fact that some
> approximations are not accurate enough

I don't agree that NaN is an appropriate approximation of 1. But
what's even the point of stating this? Not to even bother to try and
fix it upstream because you think it's good enough already?

> I would expect a performance penalty. I do not consider the issue serious
> enough to justify an arbitrary performance penalty, so a proposal
> should be first measured before committed.

So, you like octave because it serves you garbage faster? The
traditional approach to optimization starts with working code and
attempts to make it faster. Demanding that correct code be as fast as
broken code is somewhat a novel stance. Frankly, I'm not confident
that numerical accuracy is important upstream. The C standard
libraries have always placed performance as the priority over
numerical accuracy and directed people that demand accuracy to
specialized libraries (such as GSL). Perhaps the "correct"
implementation is *always* going to be slower.

> And I've checked that my gcc 4.3.3 implements complex tanh simply as 
> sinh/cosh.
> perhaps an optimization is interfering here?

Picking up compiler optimization problems is why octave needs a
numerical accuracy battery (but I get the impression it is
discouraged--hear no failures, see no failures, blame others for
failures). What do you get for the tanh bug that was fixed upstream 5
years ago:

> tanh(complex(0,pi/2))
> tanh(complex(0,3*pi/2))

On my machine the fix (if it ever existed) is gone:

octave> tanh(complex(0,pi/2))
ans = 0.0000e+00 + 1.6332e+16i
octave> tanh(complex(0,3*pi/2))
ans = -0.0000e+00 + 5.4439e+15i

Why didn't anyone know that this regression had recurred?

> Let me reverse your question somewhat: What's so special about GSL
> that makes you think a regression in GSL is much less probable?

Ugh. Really?


--judd


reply via email to

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