No, there's nothing to worry about ( when doing floating point operations on < 52 bit ints stored in doubles ). Floating point errors come from the inability to represent a number accurately within the available precision. No error is loss when the number can be accurately represented within the available precision.
Update: Added the text in bold parens for clarity.
| [reply] [d/l] [select] |
$nv = 2**33;;
printf "%.f\n", $nv;;
8589934592
printf "%d\n", $nv;;
-1
print $nv;;
8589934592
print $nv & 1;;
1
print $nv;;
8589934592
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
Joost asks:
can floating point arithmatic on integers (I mean operations on < 52 bit ints stored in doubles) lose precision?
BrowserUK writes:
printf "%d\n", $nv;;
print $nv & 1;;
Neither printf "%d" nor $nv & 1 is "floating point arithmatic".
| [reply] [d/l] [select] |
Not "floating point arithmetic", but they are "operations on < 52 bit ints stored in doubles", which is after all what he said; "I mean ...".
But, by the by, I also left it to his judgement to reach a conclusion. I know mine. I know yours. Most people here do. Now he, and everyone else can make up their own minds whether the transition from IVs to NVs is transparent; or flawed and dangerous.
From my perspective, it is impossible to code the use and manipulation of integral values in such a way that you can benefit from the extended range that storing those integrals in an NV permits, without also coding such that you never treat those integrals as integers. Ie. as IVs.
That means never using %d. Never using bitwise opcodes. Never reading or writing binary values. and much more. If these operations were not useful, then there would be no purpose of having them. In Perl or C or assembler. Hell. The chip manufacturers should simply remove 50% of their opcodes & microcode and reassign the transistors. What are they thinking of.
But the reality is, they are useful. They perform and permit algorithms that cannot be easily (never mind efficiently), be coded without the much maligned "bit-twiddling". With extremely rare and specialist exception, every computer language incorporates integer (as in fixed-length, power of 2 bits, hardware dependant sized) operations. And for a very large percentage of computer programs, they are all that is needed.
And the programs that avoid the use of floating point math, also avoid the vagaries of of it's many failure modes.
Whilst I love the concept of Perl's transparent transitions between different storage classes of number, the reality of perl's implementation is so flaky that I cannot endorse reliance upon it for anything vaguely critical. Even perl's floating point operations on floating point values are suspect:
perl -e"print 4.5 % -1.25"
0
\ruby\bin\ruby -e"print 4.5 % -1.25"
-0.5
perl -e"print 4.5 % 1.25"
0
\ruby\bin\ruby -e"print 4.5 % 1.25"
0.75
Given the wikipedia (assuming you consider that reasonably authoritative on this matter), for the modulo operator:
Given two numbers, a and n, a modulo n (abbreviated as a mod n) is the remainder, on division of a by n.
Which seems more correct to you?
Of course, the answer may be that they are both suspect. Wikipedia goes on to say:
Although typically performed with a and n both being integers, many computing systems allow other types of numeric operands.
And if you try those operations in a language that arguably takes great pains to get it's math right:
Prelude> 4.5 `mod` 1.25
<interactive>:1:4:
Ambiguous type variable `a' in the constraints:
`Integral a' arising from use of `mod' at <interactive>:1:4-8
`Fractional a' arising from the literal `4.5' at <interactive>:1
+:0-2
Probable fix: add a type signature that fixes these type variable(
+s)
then you might reach the conclusion that even the much vaunted use of % 2 as a substitute for & 1, so as to benefit from the transparent transition to > 32-bit integral values is suspect.
I do, but you're free to reach your own conclusions. Just as joost is.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] [select] |