[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R: Octave 3.1.55 available for ftp
|
From: |
Jaroslav Hajek |
|
Subject: |
Re: R: Octave 3.1.55 available for ftp |
|
Date: |
Sat, 28 Mar 2009 09:18:26 +0100 |
On Sat, Mar 28, 2009 at 7:28 AM, Marco Atzeri <address@hidden> wrote:
>
> --- Ven 27/3/09, Jaroslav Hajek ha scritto:
>
>> Da: Jaroslav Hajek
>> Oggetto: Re: R: Octave 3.1.55 available for ftp
>> A: "Marco Atzeri"
>> Cc: "octave maintainers mailing list" , "John W. Eaton"
>> Data: Venerdì 27 marzo 2009, 20:51
>> On Fri, Mar 27, 2009 at 4:43 PM,
>> Marco Atzeri <address@hidden>
>> wrote:
>> >
>> > --- Gio 26/3/09, John W. Eaton ha scritto:
>> >
>> >> Da: John W. Eaton
>> >> Oggetto: Octave 3.1.55 available for ftp
>> >> A: "octave maintainers mailing list" <address@hidden>
>> >> Data: Giovedì 26 marzo 2009, 05:04
>> >> A new snapshot of Octave is now
>> >> available from ftp.octave.org in the
>> >> directory /pub/octave/bleeding-edge:
>> >
>> >>
>> >>
>> >
>> > Hi John,
>> > I made the test on HG snapshot one day before 3.1.55,
>> > so I assume it is almost the same:
>> >
>> > Built on Cygwin-1.7.0-44 latest (development)
>> snapshot
>> >
>> > The fltk backend is built but the plot page
>> > is full of garbage. I will investigate.
>> >
>> > For the rest:
>> >
>> > src/data.cc ............. PASS 502/509 FAIL 7
>> > scripts/help/doc.m ...... PASS 0/1 FAIL 1
>> > (this fault is due to Cygwin and should be
>> solved in next
>> > development snapshot)
>> >
>> >
>> > Summary:
>> >
>> > PASS 5683
>> > FAIL 8
>> >
>> > the data fails are related to Inf position in a sort
>> >
>> >
>> >
>> **********************************************************
>> >>>>>> processing
>> /pub/hg/octave_local/src/data.cc
>> > ***** assert(log2(complex(0,Inf)), Inf + log2(i));
>> > !!!!! test failed
>> > assert (log2 (complex (0, Inf)),Inf + log2 (i))
>> expected
>> > Inf + 2.266i
>> > but got
>> > NaN + 2.266i
>> > NaNs don't match ***** assert (sort ([NaN, 1i, -1,
>> 2, Inf], "descend"), [NaN, Inf, 2, -1, 1i])
>> > !!!!! test failed
>> > assert (sort ([NaN, 1i, -1, 2, Inf], "descend"),[NaN,
>> Inf, 2, -1, 1i]) expected
>> > NaN + 0i Inf + 0i 2 + 0i -1
>> + 0i 0 + 1i
>> > but got
>> > NaN + 0i 2 + 0i -1 + 0i 0
>> + 1i Inf + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> > ***** assert (sort ([NaN, 1i, -1, 2, Inf], 2,
>> "descend"), [NaN, Inf, 2, -1, 1i])
>> > !!!!! test failed
>> > assert (sort ([NaN, 1i, -1, 2, Inf], 2,
>> "descend"),[NaN, Inf, 2, -1, 1i]) expected
>> > NaN + 0i Inf + 0i 2 + 0i -1
>> + 0i 0 + 1i
>> > but got
>> > NaN + 0i 2 + 0i -1 + 0i 0
>> + 1i Inf + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> > ***** test
>> > [v, i] = sort ([NaN, 1i, -1, Inf, 1, 1i]);
>> > assert (v, [1, 1i, 1i, -1, Inf, NaN])
>> > assert (i, [5, 2, 6, 3, 4, 1])
>> > !!!!! test failed
>> > assert (v,[1, 1i, 1i, -1, Inf, NaN]) expected
>> > 1 + 0i 0 + 1i 0 + 1i
>> -1 + 0i Inf + 0i NaN + 0i
>> > but got
>> > 0 + 1i -1 + 0i Inf + 0i 1
>> + 0i 0 + 1i NaN + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> > ***** assert (sort (single([NaN, 1i, -1, 2, Inf]),
>> "descend"), single([NaN, Inf, 2, -1, 1i]))
>> > !!!!! test failed
>> > assert (sort (single ([NaN, 1i, -1, 2, Inf]),
>> "descend"),single ([NaN, Inf, 2, -1, 1i])) expected
>> > NaN + 0i Inf + 0i 2 + 0i -1
>> + 0i 0 + 1i
>> > but got
>> > NaN + 0i 2 + 0i -1 + 0i 0
>> + 1i Inf + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> > ***** assert (sort (single([NaN, 1i, -1, 2, Inf]),
>> 2, "descend"), single([NaN, Inf, 2, -1, 1i]))
>> > !!!!! test failed
>> > assert (sort (single ([NaN, 1i, -1, 2, Inf]), 2,
>> "descend"),single ([NaN, Inf, 2, -1, 1i])) expected
>> > NaN + 0i Inf + 0i 2 + 0i -1
>> + 0i 0 + 1i
>> > but got
>> > NaN + 0i 2 + 0i -1 + 0i 0
>> + 1i Inf + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> > ***** test
>> > [v, i] = sort (single([NaN, 1i, -1, Inf, 1, 1i]));
>> > assert (v, single([1, 1i, 1i, -1, Inf, NaN]))
>> > assert (i, [5, 2, 6, 3, 4, 1])
>> > !!!!! test failed
>> > assert (v,single ([1, 1i, 1i, -1, Inf, NaN]))
>> expected
>> > 1 + 0i 0 + 1i 0 + 1i
>> -1 + 0i Inf + 0i NaN + 0i
>> > but got
>> > 0 + 1i -1 + 0i Inf + 0i 1
>> + 0i 0 + 1i NaN + 0i
>> > Infs don't matchshared variables {
>> > m2 =
>> >
>> > 1 2
>> > 3 4
>> >
>> > flo = 0
>> > fhi = Inf
>> > }
>> >
>> >
>> **********************************************************
>> >
>> > Regards
>> > Marco
>> >
>>
>> Since I don't see those problems (and neither probably do
>> most
>> others), I can only make wild guesses that this may be a
>> Cygwin gcc
>> problem, especially if you compiled with gcc 3.
>>
>> I assume isnan works correctly when applied to the arrays
>> used in the
>> test? In that case, my wild guess is that gcc 3 is not
>> correctly
>> recognizing the sort_isnan specializations in Array-C.cc
>> and
>> Array-fC.cc.
>>
>> Does maybe the attached workaround fix the issue?
>>
>> cheers
>>
>> --
>> RNDr. Jaroslav Hajek
>
> Hi Jaroslav,
>
> gcc-4.3.2
>
> isnan is working, but it seems an issue related to
> max/min when Inf is present in a complex number.
>
>
> octave:10> a=1/0+i
> warning: division by zero
> a = Inf + 1i
> octave:11> b=0/0+0i
> warning: division by zero
> b = NaN
> octave:12> c=-1/0+2i
> warning: division by zero
> c = -Inf + 2i
> octave:13> max([a,b,c,i])
> ans = Inf + 1i
> octave:14> min([a,b,c,i])
> ans = Inf + 1i ????
> octave:15> sort([a,b,c,i])
> ans =
>
> Inf + 1i -Inf + 2i 0 + 1i NaN + 0i
>
> octave:21> min([b,c,a,i])
> ans = -Inf + 2i
> octave:22> max([b,c,a,i])
> ans = -Inf + 2i
>
>
> octave:16> isnan(a)
> ans = 0
> octave:17> isnan(b)
> ans = 1
> octave:18> isnan(c)
> ans = 0
> octave:19> isnan(i)
> ans = 0
>
> for real number the issue is not present
>
> octave:1> a=1/0
> warning: division by zero
> a = Inf
> octave:2> b=0/0
> warning: division by zero
> b = NaN
> octave:3> isnan(b)
> ans = 1
> octave:4> isnan(a)
> ans = 0
> octave:5> max([a,b,1])
> ans = Inf
> octave:6> c=-1/0
> warning: division by zero
> c = -Inf
> octave:7> max([a,b,c,1])
> ans = Inf
> octave:8> min([a,b,c,1])
> ans = -Inf
> octave:9> sort([a,b,c,1])
> ans =
>
> -Inf 1 Inf NaN
>
>
> I doubt it is a sort problem.
> Do you still need the test ?
> I think the problem could be also here:
>
>
> [b,c,a,i]
> ans =
>
> NaN + 0i -Inf + 2i Inf + 1i 0 + 1i
>
> octave:30> abs([b,c,a,i])
> ans =
>
> NaN NaN NaN 1 ???
>
> octave:31> abs(c)
> ans = Inf look right
>
>
> This problem does not exist in 3.0.3
>
> octave:1>[1/0+i,-1/0-2i,i,0/0]
> ans =
>
> Inf + 1i -Inf - 2i 0 + 1i NaN + 0i
>
> octave:2>abs([1/0+i,-1/0-2i,i,0/0])
> ans =
>
> Inf Inf 1 NaN
>
> octave:3> sort([1/0+i,-1/0-2i,i,0/0])
> ans =
>
> 0 + 1i -Inf - 2i Inf + 1i NaN + 0i
>
>
>
> Regards
> Marco
>
>
>
>
OK, it's apparent that the problem is deeper - seems that std::abs
does not work well with infinite complex numbers on cygwin. Can you
verify?
#include <iostream>
#include <complex>
int main()
{
double a = 0;
double b = 1. / a;
a += 1;
std::cout << std::abs (std::complex<double> (b, a)) << '\n';
}
I'm not sure what's best here, if this is true - I don't much like the
idea of working around std::abs by explicit isinf & isnan checks,
because that's going to slow things down unnecessarily on platforms
where std::abs works correctly.
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz