Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^12: unintentional conversion of signaling NaN to quiet NaN

by BrowserUk (Patriarch)
on Jun 27, 2016 at 08:34 UTC ( [id://1166636]=note: print w/replies, xml ) Need Help??


in reply to Re^11: unintentional conversion of signaling NaN to quiet NaN
in thread unintentional conversion of signaling NaN to quiet NaN

It allows me to get the same output as you, but I don't know that it proves the problem is in SvNV() because it also avoids sv_setnv().

The problem is that none of the macros&functions just do what they are named to do; and it is impossible to work out exactly what they really do if you are not a compiler!

For example. In the following version I replaced the direct assignment of the bit pattern to the NV field with sv_setnv(). It works(???), in as much as printing the value of the scalar as a float produces 1.#SNAN (for me); but the purpose of the exercise -- using the PV pointer to get at the NV memory direct -- fails, because as well as performing the assignment of the NV, the function also changes the type of the SV that I carefully construct as a SvPVNV, to ... something else, so all my shenanigans with the PV pointer are wasted.

However, the fact that setting the bit pattern with sv_setnv() results in 1.#SNAN output from printf proves that it (on my system. ie. compiled with MSVCv???) isn't messing with the value on the way in; which puts the problems of viewing the bit pattern firmly in the pack'd'/'F' and thus SvNV????().

With the code you just provided, running Devel::Peek::Dump($snan); crashes

That unsurprising given what I'm doing with the SV.

I was reluctant to draw this diagram as there is always gonna be some pedant that gonna come back with: "That's a lie! SV's don't look like that on version 5.2017 on a Raspberry Pie with a 65-bit LEG processor manufactured by the Cray Twins."

Suffice to say, the following diagram is representational, and doesn't necessarily reflect any version of reality:

Notionally, a fully loaded SV looks vaguely like this: SV*->[ SVANY ]->[ IV ] [ FLAGS ] [ NV ] [ PV ]->"some text" What my code above does is this: SV*->[ SVANY ]->[ IV ] [ FLAGS ] [ NV ]<-+ [ PV ]--+ Point the PV at the memory holding th +e NV.

The problem is that, having messed with the pointer, I haven't fixed up SV_CUR and SV_LEN, so it is unsurprising that Devel::Peek gets confused. (I did warn it was trick! :)

The CCFLAGS setting in the I::C config has no impact afaict.

I set that in an attempt to get debug symbols that would to allow me to trace into the ICexample.DLL with the debugger. It was not successful.

The overall lesson is that when you try to inspect the content of an NV via unpack 'd'/'F', something is causing its value to be loaded into a floating point register; and as soon as you do that, regardless of whether you perform any actual mathematical operation on it, the FPU will silent convert SNANs to QNaNs.

The purpose of pointing the PV at the NV is to allow you to inspect the bit patterns without using unpack 'd'/'F'; and that seems to work for you.

I'm surprised by the failure of the unpack 'h*' on a 32-bit perl; but if you're only concerned with 32-bit perls that have 'Q', then you don't need that anyway, so no matter.

As for exactly what is causing unpack 'd'/'F' to load the value into an FP register -- there is certainly no reason for it to do so -- I don't have a clue, if it isn't that addition of -0.0.

However, I will say that the addition of -0.0 makes no sense. The documented reason -- the "preservation of ieee negative zero" -- just doesn't stand up to scrutiny. The comment say:

Need -0.0 for SvNVX to preserve IEEE FP "negative zero" because +0.0 + -0.0 => +0.0 but -0.0 + -0.0 => -0.0 */

Which means: if the value is positive zero, adding negative zero will leave it positive; but if it is already negative zero, it will remain negative.

In other words; its a bloody noop! At least in terms of the signedness of zeros. But, the very action of loading the value into FPU register to perform that pointless noop, means that SNaNs will be converted to QNaNs!

Ie. The very problem you are seeing and why it is such a tempting target for my accusation; even if ultimately that particular piece of code isn't being conditionally compiled.

If it isn't the ultimate cause, it should still be removed; and you (they) need to look for something similar elsewhere.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1166636]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2024-03-28 19:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found