Re: log2 on MinGW

[Rik]

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.

--Rik

logdemo.cpp
Description: Text Data