Dear Jens, Richard B. Kreckel wrote:
On 2008-08-21, I wrote:
Ah, I haven't had my morning coffee yet. So I forgot to include the bug of the day:
factor(x); Segmentation fault
That's fixed now. Thank you!
Now, I'm getting
factor(expand((x+64*x^4)*(3*x+92*x^4+5*x^2))); Segmentation fault
Is this in any way related with this issue?
factor(x^37+1); Not a 32-bit integer: 137438953472
That's fixed now. Thank you! Now, I'm getting:
factor(expand((77+102*x^4+27*x+11*x^3+25*x^2)*(85+66*x^4+29*x+57*x^3+92*x^2))); Not a 32-bit integer: 2955677175 Woops! Sorry for being a nuisance. ;-) Well, it's easily fixed with this patch: diff --git a/ginac/factor.cpp b/ginac/factor.cpp index 886819a..9081052 100644 --- a/ginac/factor.cpp +++ b/ginac/factor.cpp @@ -124,8 +124,8 @@ struct UniPoly // assert: poly is in Z[x] Term t; for ( int i=poly.degree(x); i>=poly.ldegree(x); --i ) { - int coeff = ex_to<numeric>(poly.coeff(x,i)).to_int(); - if ( coeff ) { + cl_I coeff = the<cl_I>(ex_to<numeric>(poly.coeff(x,i)).to_cl_N()); + if ( !zerop(coeff) ) { t.c = R->canonhom(coeff); if ( !zerop(t.c) ) { t.exp = i; This leaves me wondering whether other numeric -> int conversions should be treated likewise. What about gamma inside the hensel_univar function? I don't know what it is. Can we assume with reasonable certainty that it fits the target unsigned int format? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>