[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Same .m file: different results with different versions of Octave
From: |
Jaroslav Hajek |
Subject: |
Re: Same .m file: different results with different versions of Octave |
Date: |
Mon, 19 Apr 2010 08:08:41 +0200 |
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
- Re: Same .m file: different results with different versions of Octave, (continued)
- Re: Same .m file: different results with different versions of Octave, John W. Eaton, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, John W. Eaton, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/18
- Re: Same .m file: different results with different versions of Octave, Juergen Rose, 2010/04/19
- Re: Same .m file: different results with different versions of Octave,
Jaroslav Hajek <=
- Re: Same .m file: different results with different versions of Octave, Søren Hauberg, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Søren Hauberg, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Jaroslav Hajek, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19
- Re: Same .m file: different results with different versions of Octave, Judd Storrs, 2010/04/19