Re: log2 on MinGW

[Michael Goffioul]

On Sun, Nov 3, 2013 at 8:10 PM, Rik <address@hidden> wrote:

On 11/03/2013 03:02 PM, address@hidden wrote:
> Message: 1
> Date: Sun, 3 Nov 2013 13:55:10 -0800 (PST)
> From: PhilipNienhuis <address@hidden>
> To: address@hidden
> Subject: Re: minGW 'make check' errors
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Rik-4 wrote
>> > 11/3/13
>> >
>> > This bug report details some errors which apparently only appear on the
>> > minGW system (https://savannah.gnu.org/bugs/?32036).
>> >
>> > Specifically, it seems that log2 (Inf) = Inf on all other platforms and
>> > NaN
>> > on minGW.  Given that minGW is linking against Windows math libraries, and
>> > I don't see Microsoft changing anytime soon, I think we should make
>> > exceptions for these two tests when minGW is detected.  After all,
>> > reporting them as failures isn't going to change Octave's code (log2(Inf)
>> > should be Inf), nor is it going to be a spur to Microsoft to change their
>> > libraries.  Thus, the point of a failing test being a prod to get
>> > something
>> > fixed is rendered moot.
> Is that true, that it is Windows' low-level math libs that screw up? I'd
> expect that they are as tied to the HW (CPU/FPU) as e.g., Linux low-level
> math libs. I really see no reason for Microsoft to stick to returning
> inappropriate numeric exception values given the enormous proliferation of
> Windows in the engineering and scientific world. But I really don't know the
> exact details.
>
> I'd rather expect that it is MinGW runtime math libs ("upstream") that get
> things wrong. An example of MinGW low-level code is here:
> https://www.gitorious.org/mingw/mingw-runtime/source/77108e3eb6c1896f3d1aa5ad7dcd2d8225280125:mingwex/math/powl.c
> My C/C++ skills surely are somewhat lacking but this code piece suggests me
> it cannot be ruled out yet that the key is in the MinGW math libs.
> FYI, Python seems to have wrappers for special values, see:
> http://bugs.python.org/review/11888/diff/2544/Modules/mathmodule.c?context=75&column_width=80
> Wrappers give me a taste of performance hits, but maybe they can be
> implemented cleverly.
>
> Makes me wonder what Michael Goffioul's MSVC binaries make of it.
>
> But before filing bug reports upstream we'd need to be very sure it isn't in
> any way Octave's fault that we get Inf vs. NaN or vice versa on MinGW.
>
> We probably cannot compare with Matlab - that is I've read rumours that ML
> supplies its own math libraries. But I'll try to test it at work. Stupid of
> me, never thought of it.
>
> Anyway, this bug report isn't in the way. Maybe someday, somehow we'll find
> a fix for it.
>
> Philip
11/3/13

Philip,

Why not try compiling the attached program with MinGW and running it.  The
compile command will be something like "g++ -lm logdemo.cpp -o logdemo".
It calls log2 from the math library without any intervening Octave code.

I don't believe the problem is in the log2 implementation. If you look at the bug report, you'll note it's happening in octave for log2 returning 2 output arguments, which is internally translated by octave into frexp calls. So the problem lies in Win32 implementation of frexp when the input argument is Inf.

gnulib provides an implementation of frexp, however I'm wondering whether gnulib's implementation can be considered sub-optimal, as it has to be generic, compared to the internal Win32 implementation, which can use assembly. I truly don't know, I never tried to compare performance.

What I use as a workaround in my 3.6.4 binaries was to patch octave with this:

diff -ur octave-3.6.4-rc1/liboctave/lo-mappers.cc octave-3.6.4-rc1-new/liboctave/lo-mappers.cc

--- octave-3.6.4-rc1/liboctave/lo-mappers.cc 2012-10-18 19:56:23 +0100

+++ octave-3.6.4-rc1-new/liboctave/lo-mappers.cc 2013-01-05 03:17:28 +0000

@@ -136,6 +136,8 @@

 double

 xlog2 (double x, int& exp)

 {

+  if (xisinf (x))

+    return x;

   return frexp (x, &exp);

 }

 

@@ -356,6 +358,8 @@

 float

 xlog2 (float x, int& exp)

 {

+  if (xisinf (x))

+    return x;

   return frexpf (x, &exp);

 }

Michael.