Re: Problems with number resolution

The math and me! The more illuminated brothers may forgive me. But using Math::BigFloat i get the results you expect:

#!/usr/bin/env perl

use strict;
use warnings;
use Math::BigFloat;
use feature qw(say);

my $x = Math::BigFloat->new(0);

my @nr = ( '32431.19', '20', '-10', '-31800' );

foreach (@nr) {
    $x += $_;
    say qq($_\t=>\t$x);
}

__END__
karls-mac-mini:playground karl$ ./math.pl
32431.19    =>    32431.19
20    =>    32451.19
-10    =>    32441.19
-31800    =>    641.19
[download]

Best regards, Karl

ŤThe Crux of the Biscuit is the Apostropheť

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Comment on Re: Problems with number resolution Select or Download Code

Replies are listed 'Best First'.
Re^2: Problems with number resolution by Laurent_R (Canon) on Jan 02, 2018 at 18:30 UTC
Yes, Math::BigFloat probably does it right. But it may be quite slow. When dealing with monetary value having typically 2 decimal places, many (most ?) business databases actually store monetary values as integers with a scale factor of two (in other words, they store internally monetary amounts in cents instead of dollars or euros and perform the necessary conversions when needed). I guess this is deemed to be more accurate and probably faster. For tariffs related with usually small amounts (such as rating telephone calls), I have seen price rates actually stored internally as integers in 1/10,000 of a euro. But anytime the database engine reads from the database or writes to it, the scaling factor is applied. Most people using the database or even developing for it don't ever get to see this, as this is buried deep in the very low levels of the database software.	[reply]

Replies are listed 'Best First'.

Re^2: Problems with number resolution
by Laurent_R (Canon) on Jan 02, 2018 at 18:30 UTC

Math::BigFloat

When dealing with monetary value having typically 2 decimal places, many (most ?) business databases actually store monetary values as integers with a scale factor of two (in other words, they store internally monetary amounts in cents instead of dollars or euros and perform the necessary conversions when needed). I guess this is deemed to be more accurate and probably faster. For tariffs related with usually small amounts (such as rating telephone calls), I have seen price rates actually stored internally as integers in 1/10,000 of a euro. But anytime the database engine reads from the database or writes to it, the scaling factor is applied. Most people using the database or even developing for it don't ever get to see this, as this is buried deep in the very low levels of the database software.

[reply]