Log2 and beta test failures

[Ben Abbott]

On Monday, May 05, 2008, at 03:41PM, "Michael Goffioul" <michael.goffioul at gmail.com> wrote:
>On Mon, May 5, 2008 at 9:33 PM, Ben Abbott <bpabbott at mac.com> wrote:
>>  I'm using gcc 4.3 as well with -O3 and see the same test failure that John sees with -O.
>>
>>  I don't see the others, which Michael encountered (later I'll try building with -O2 to see if the log2 feature goes away).
>>
>>  Regarding the log2 feature, I noticed log gives the expected result
>>
>>  octave:12> log(complex(0,inf))
>>  ans = Inf + 1.571i
>>
>>  and that
>>
>>  octave:13> log(complex(0,inf))/log(2)
>>  ans = Inf - NaNi
>>
>>  gives a result consistent with log2. I assume that the "log(2)" is being treated as a complex number?
>>
>>  I'm not proficient in c/c++, but I suspect the log2 feature originates in lo-mappers.cc
>>
>>  Complex
>>  xlog2 (const Complex& x)
>>  {
>>  #if defined (M_LN2)
>>   static double ln2 = M_LN2;
>>  #else
>>   static double ln2 = log (2);
>>  #endif
>>
>>   return std::log (x) / ln2;
>>  }
>>
>>  Might the return be modified to something like
>>
>>  y = log(x);
>>  return std:: complex(real(y)/ln2, imag(y)/ln2);
>
>I had more the impression that the problem comes from the
>other form of xlog2, with 2 input arguments. That form simply
>calls frexp, and I suspect that the Win32 version of frexp
>returns something different than what's expected for
>infinite input.
>
>Michael.

My guess was predicated upon an earlier discussion on another thread.

My thought was that

  complex(0,Inf) * complex(1,0) should equal complex(NaN, Inf)

while (with out elevating real number to complex numbers)

  complex(0,Inf) * real(1) should equal complex(0, Inf)

However, as I unfamiliar with how Octave handles such things internally, so I may be way off in my supposition.

It is also possible that more than one cause to the effects you're seeing. Is there any reason to suspect that the log2 feature is related to the beta feature?

Ben