Skip Menu |

This queue is for tickets about the Math-BaseCalc CPAN distribution.

Report information
The Basics
Id: 77198
Status: open
Priority: 0/
Queue: Math-BaseCalc

People
Owner: Nobody in particular
Requestors: BBYRD [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.016
Fixed in: (no value)

Attachments


Subject: from_base truncation of large integers
use v5.10; use bigint; use Math::BaseCalc; my $bignum = 85863250553302448437153211102345904505502971929758795587130289554944; my $base89 = [0..9, 'A'..'Z', 'a'..'z', split(//, '#$%&()*+,-/:;<=>?@[]^_`{|}~')]; # no !, ., ', ", or \ my $calc89 = Math::BaseCalc->new(digits => $base89); my $hash = $calc89->to_base($bignum); my $newnum = $calc89->from_base($hash); say "BaseCalc via Base89"; say "==================="; say $bignum; say $hash; say $newnum; say $newnum + 0; say; my $calc64 = Math::BaseCalc->new(digits => '64'); $hash = $calc64->to_base($bignum); $newnum = $calc64->from_base($hash); say "BaseCalc via Base64"; say "==================="; say $bignum; say $hash; say $newnum; say $newnum + 0; # BaseCalc via Base89 # =================== # 85863250553302448437153211102345904505502971929758795587130289554944 # jCT3jUmD]hEtieNUC:y+`0gn$XmrbzR4U9x # 8.58632505533025e+67 # 85863250553302500000000000000000000000000000000000000000000000000000 # # BaseCalc via Base64 # =================== # 85863250553302448437153211102345904505502971929758795587130289554944 # MvUgAAACIAAQAAADz/8/////////////8AgAYA # 8.58632505533024e+67 # 85863250553302400000000000000000000000000000000000000000000000000000
One way to deal with this would be to turn on 'bigint', if it's available, inside from_base(). I don't have a sense of the performance penalty that would impose though. And it would mean the return value is different than people's code might be expecting - right now it's documented to return a vanilla numeric scalar. Do you have a suggested fix that's different?
On Mon May 14 15:15:33 2012, KWILLIAMS wrote: Show quoted text
> Do you have a suggested fix that's different?
Lemme see. I've had some familiarity with this for the SQL_FUNCTIONS_CONV thing I wrote for SQL::Statement (RT #72638). I'm going to go back to that code to see which pitfalls I ran into... I solved the performance issues by predicting the number of digits ahead of time and using (or not using) Math::BigInt/Float only when I needed to, as well as putting in a bunch of oct/sprintf short-circuits. ...... Okay, I have something which fixes several issues (basically all of the stuff I found from building CONV), but it's late, so I'll post the patch tomorrow.
First of all, my apologies for the massive refactoring, but the whole module should be better for it. The list of changes are detailed in the Changes file. The new code will use Math::Big* right off the bat, as I realized that not using it isn't going to gain much speed. (Perl has an accuracy limit of around 14 digits, so using standard scalars for only 14 iterations of a loop is barely a blip on the radar.) Please let me know if you have any questions around the code. I will be using this module as a dependency for a pragma module of mine, so I'd like to get this out the door as soon as you're ready.
Subject: Math-BaseCalc-v1.2.patch.gz
Download Math-BaseCalc-v1.2.patch.gz
application/x-gzip 8.3k

Message body not shown because it is not plain text.

Sorry to bug you, but did you get a chance to look at this one?
Hi Brendon, very sorry to take so long to look at this. I applied your patch but I'm getting a lot of test errors. Almost all of them look like this: # Failed test 'from( to ( 2.5 ) == .0,. --> 2.5 (using 0,.)' # at t/02_digit_dash_dot.t line 28. # got: '25e-1' # expected: '2.5' It's over-eager to use scientific notation. I've also imported the code to Github, your patch is on the 'bbyrd' branch.
On Sat Jun 16 00:03:07 2012, KWILLIAMS wrote: Show quoted text
> Hi Brendon, very sorry to take so long to look at this.
No problem. Sorry for being impatient. Show quoted text
> I applied your patch but I'm getting a lot of test errors. Almost all > of them look like this: > > # Failed test 'from( to ( 2.5 ) == .0,. --> 2.5 (using 0,.)' > # at t/02_digit_dash_dot.t line 28. > # got: '25e-1' > # expected: '2.5' > > It's over-eager to use scientific notation. > > I've also imported the code to Github, your patch is on the 'bbyrd' > branch.
Have you tested with that branch? I'm getting a clean result, on both my Win32 laptop and Linux VM. Note that I did need to do some test changes as well, so the patch isn't just BaseCalc.pm. (Though, the bbyrd branch does reflect that.) I'm submitting a pull request, but it's only to fix some minor issues. The other branch should still pass tests.