in reply to Re^3: \$var == 1 fails when \$var = 1
in thread \$var == 1 fails when \$var = 1

That sort of makes sense :-) Is there a module that covers over these sort of cracks? It would seem to be a routine problem.

Replies are listed 'Best First'.
Re^5: \$var == 1 fails when \$var = 1
by syphilis (Bishop) on Sep 21, 2018 at 02:07 UTC
Is there a module that covers over these sort of cracks?

The crack that has perl's print() function often lie to us about a floating point value is rather annoying.
You just need to remember that the floating point value that print() provides will be the same as that provided by printf "%.14e", whereas, if you want a practically useful value, you need to printf "%.16e".
Outputting more than 17 decimal digits of a double is generally of no use. If you want to see the exact value, use printf "%a" (which will display that exact value in hex).

I gather that there was once a \$# special variable (see perldoc perlvar) which allowed one to specify the decimal precision that print() would use.
But it has been abandoned and disabled owing to difficulties in its implementation.
You can, of course, write your own subroutine for printing floats in the format of your choice:
```sub p17 {
printf "%.16e\n", \$_;
}

sub ph {
printf "%a\n", \$_;
}
The breaking of the Associative Law of Addition that you experienced is something that can happen when floating point operations overflow the fixed precision.
To be guaranteed of avoiding that, I think you'd need to work in an environment that avoids overflow by allowing the precision to increase as needed.
Math::BigFloat does appear to provide that.

Cheers,
Rob
Re^5: \$var == 1 fails when \$var = 1
by LanX (Archbishop) on Sep 20, 2018 at 15:43 UTC
Many, but they slow down calculation by using number objects and overloading operators.

As already said, if it matters, like with currencies, I just keep adding cents.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice