Perl Monk, Perl Meditation | |
PerlMonks |
Re^6: Converting bytes to floatsby syphilis (Archbishop) |
on Apr 18, 2023 at 12:38 UTC ( [id://11151733]=note: print w/replies, xml ) | Need Help?? |
.... but swapping entire bytes ... In addition to the endianness issue, there's also the "precision" issue that can trip one up when print()ing NV values. On a perl whose nvtype is double: On a perl whose nvtype is the 80-bit extended precision long double: On a perl whose nvtype is either the IEEE 754 long double or the __float128: You might think that the differences in those 3 one liners occur because pack 'd', sqrt 2 has returned different bytes in each of those 3 one liners, but that's not so. In each of those 3 one-liners pack 'd', sqrt 2 returned exactly the same byte. So, it must be that the unpacking returned different values ? Wrong again. It's the way that perl's print() function conceals the actual value returned by unpack 'd', pack 'd', sqrt 2 that accounts for the anomalies. Perl is bullshitting in all 3 cases (and knows it). On a perl whose nvtype is double: On a perl whose nvtype is the 80-bit extended precision long double: On a perl whose nvtype is either the IEEE 754 long double or the __float128: 3 different renditions of the same value - none of them accurate. I recall a quote (probably from Larry) from a while ago, along the lines of "perl makes the hard things easy". When it comes to certain aspects of the way perl deals with NVs, it's more a case of "perl makes the easy things hard". I think it's ridiculous and, although I'm scathing of it, I'm also used to it and sort of like the way that it keeps me on my toes ;-) So ... for a given $byte, what one expects to be returned by unpack "d", $byte can depend not only upon machine endianness, but also on NV type. Cheers, Rob
In Section
Seekers of Perl Wisdom
|
|