octave-maintainers
[Top][All Lists]
Advanced

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

Re: Log2 and beta test failures


From: Jaroslav Hajek
Subject: Re: Log2 and beta test failures
Date: Tue, 6 May 2008 10:51:29 +0200

On Tue, May 6, 2008 at 10:33 AM, Jaroslav Hajek <address@hidden> wrote:
> On Tue, May 6, 2008 at 10:05 AM, Michael Goffioul
>
> <address@hidden> wrote:
>
>
> > On Tue, May 6, 2008 at 8:35 AM, Jaroslav Hajek <address@hidden> wrote:
>  >  >  I don't have other g++ versions or compilers to try. Ben, Michael, can
>  >  >  you try this fragment with your configurations? I don't see any
>  >  >  obvious bug in the xlog2 mappers, so I guess this may be the cause.
>  >
>  >  On MSVC, I get (0,inf) whatever the optimization level. I did the same
>  >  with cygwin gcc-3.4.4 and it gave me (nan,inf) whatever the optimization
>  >  level.
>  >
>  >  However, the test failures I reported are not related to that, but
>  >  to the second form of xlog2:
>  >
>  >  double xlog2(double x, int& exp)
>  >
>  >  when x = Inf. This results in a call to frexp with infinite value.
>  >  I tested it under MSVC and I got:
>  >
>  >  frexp(Inf) => NaN, -1
>  >
>  >  but from the test code in src/data.cc, it seems the expected
>  >  values are
>  >
>  >  frexp(Inf) => Inf, 0
>  >
>  >  Michael.
>  >
>
>  Yes, that is what is expected and what both gcc and Intel always give.
>  I was convinced that for f = frexp (x,&e), x = f * 2^e is an
>  invariant; I'm less convinced now although gcc's and Intel's results
>  make more sense than Microsoft's. I'll try to check the C standard.
>
>

Found: The C99 standard, sec F.9.3.4 says specifically that f = frexp (x, &e)
for x +inf or -inf should give f = x and e can be any value. This is
consistent with my expectations: x = f * 2^e is an invariant of frexp.

I'd tend to regard this as a defect of MSVC, as there is probably no
other standard to follow than C99. We should, however, at least fix
the relevant test to not assume e = 0.

I'm not sure what is John's attitude about working around compiler
incompatibilities like this;
surely an additional test will make things consistent at the cost of
slowing things down.
I know Microsoft is known not to care much about standards, but I
guess they could be willing to fix this issue eventually.


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



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


reply via email to

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