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

[Jaroslav Hajek]

On Sun, Apr 18, 2010 at 10:28 PM, Judd Storrs <address@hidden> wrote:
> 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?
>

No, the point was to explain that your conclusion that "Octave doesn't
work" because of a particular suboptimal computation makes little
sense. By this logic, Octave never "worked", and probably never will,
and the same likely holds for Matlab as well as other software.

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

The problem, as explained above, is that your "working code" is
mythical. GSL apparently has a better ctanh implementation than glibc,
but even GSL uses glibc functions, only a smaller set thereof.

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

Numerical accuracy is simply just one of important factors. It's often
better to get an inaccurate result fast. I don't see why Octave should
aim for substantially better accuracy than libc.

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

No, you didn't understand; if it was true, this would be something
that really shouldn't happen. But I was mistaken, std::tanh is really
forwarded to builtin ctanh, hence the problem *is* in libc.

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

Yes. I'd like to know the answer, and to the second part of the
question as well. Why can't you just take the GSL implementation and
use it inside libc?

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz