For Programmers: Free Programming Magazines  


Home > Archive > PERL Modules > March 2006 > Math::Pari 'factor' is wrong









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Math::Pari 'factor' is wrong
gamo

2006-03-17, 6:56 pm


#!/usr/local/bin/perl -w

# use Math::PariInit qw( primes=12000000 stack=1e8 );
# use Math::Pari qw(:all);
use Math::Pari 'factor';

# $i = PARI 0;
# $P = PARI 1;

for $i (0..1_000_000_000) {
$P = 5*$i**4-10*$i**3+20*$i*$i-15*$i+11;
$f = factor($P,0);
# print "$f\n";
# next if ($f =~ /-1/);
@fact= ($f =~ /[\[|\;](\d+)\,/g);
# print "@fact\n";
for $j (@fact){
if ($j%10!=1){
print "$f -> $j factor of P($i)=$P\n";
}
}
# last if $i==1000;
}


__END__


This code gives incorrects results as -1 as factor of a positive
integer or 5 as factor of a number not terminated in 5 or 0.

I do a sample calculation using 'echo "factor(number)" | gp' and this
gives correct results.

TIA, best regards
gamo

2006-03-18, 3:55 am

Sisyphus

2006-03-18, 3:55 am


"gamo" <gamo@telecable.es> wrote in message
..
..
>
>
> This code gives incorrects results as -1 as factor of a positive
> integer or 5 as factor of a number not terminated in 5 or 0.
>
> I do a sample calculation using 'echo "factor(number)" | gp' and this
> gives correct results.
>

I think you could have provided a simpler test case:

use warnings;
use Math::Pari;

$f1 = Math::Pari::factor(72);
print $f1, "\n";

$z = 4225760561;
$f2 = Math::Pari::factor($z);
print $f2, "\n";

$p = PARI $z;
$f3 = Math::Pari::factor($p);
print $f3, "\n";

__END__

(You could, of course, further simplify the above code.) For me that
produces:

[2,3;3,2]
[-1,1;5,1;13,1;743,1;1433,1]
[-1,1;5,1;13,1;743,1;1433,1]

Quite clearly the first line is correct, since (2**3) * (3**2) == 72
Just as clearly, the second 2 lines are not what we expect.

There's obviously a problem when we get to 32-bit numbers. The unsigned long
4225760561, when treated as a signed int, becomes -69206735 - and it's not
hard to work out that the last 2 lines of output are the factorisation
of -69206735.

I'm not surprised that factor($z) in the above code returns what we see, but
I *did* think that factor($p) would have returned what you and I expected. I
think it's a bug - though I'm not an expert on Math::Pari and haven't read
the documentation very thoroughly.

As for what to do about this .... you could file a bug report at
http://rt.cpan.org/Public/Dist/Disp...?Name=Math-Pari , or you could
contact the author directly. I don't think he would mind that. (I think he
peruses this list, so he may yet respond to this thread.)

Cheers,
Rob


Ilya Zakharevich

2006-03-18, 3:55 am

[A complimentary Cc of this posting was sent to
gamo
<gamo@telecable.es>], who wrote in article <Pine.LNX.4.64.0603171934330.23094@jvz.es>:

> This code gives incorrects results as -1 as factor of a positive
> integer or 5 as factor of a number not terminated in 5 or 0.


How do you suppose we are going to treat this? Send you our
condolences? What else do you think we can do?

What version of what? What Math::Pari test suite was saying? Can you
shorten your program to 1 line?

Puzzled,
Ilya
Ilya Zakharevich

2006-03-18, 3:55 am

[A complimentary Cc of this posting was sent to
gamo
<gamo@telecable.es>], who wrote in article <Pine.LNX.4.64.0603171934330.23094@jvz.es>:
> for $i (0..1_000_000_000) {
> $P = 5*$i**4-10*$i**3+20*$i*$i-15*$i+11;


This does not make sense. Why do approximate calculations, if you
want integer arithmetic?

The correct way is (if $i fits exact Perl types)

for $j (0..1_000_000_000) {
my $i = PARI $j; # Or PARI "$j" to be absolutely sure
$P = ...

Or make a while() loop operating on a Math::Pari integer, not Perl integer.

But anyway, I discovered a bug in unsigned --> PARI conversion.
Sigh...

perl -MMath::Pari -wle "print PARI 3936116531"
-358850765

This is clearly a bug, Perl data contains enough bits of info to
deduce the correct result... >>TODO

Hope this helps,
Ilya
Ilya Zakharevich

2006-03-18, 3:55 am

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich
<nospam-abuse@ilyaz.org>], who wrote in article <dvge29$ch7$1@agate.berkeley.edu>:
> But anyway, I discovered a bug in unsigned --> PARI conversion.
> Sigh...
>
> perl -MMath::Pari -wle "print PARI 3936116531"
> -358850765


[Note that this bug is not related to the problems the poster had
due to misunderstanding of Perl arithmetic; but it may move the
threshold where problems appear.]

I released 2.010704 which has this bug fixed. (The test suite is
sensitive to details of propagation from INT to FLOAT in Perl, so may
be wrong on 64-bit platforms. Also, if somebody runs a platform where
$Config{longsize} < $Config{ivsize}, I would like to hear from you
even if test suite succeeds. ;-)

Thanks,
Ilya
gamo

2006-03-18, 7:55 am

gamo

2006-03-18, 7:55 am

Ilya Zakharevich

2006-03-18, 7:55 am

[A complimentary Cc of this posting was sent to
gamo
<gamo@telecable.es>], who wrote in article <Pine.LNX.4.64.0603181141060.22760@jvz.es>:
[color=darkred]
[color=darkred]
> That's not an approximate calculation.


Says who?

> $P It's the value of the polynomial=
> =20
> in the point $i.=20


It IS an approximate calculation. Any calculation done with Perl
numeric values is approximate. The loss of precision may happen to be
0, but this is a coincidence only.

Hope this helps,
Ilya
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com