Hi,
I have program that crashes when it uses the collect function of the ex
class. The strange error I receive is:
Not a 32-bit integer: -9223372028264841216
I am able to print both the expression and the symbol I am going to use
for the collect call before hand and all seems fine. I archived the
symbol and expression just before I knew it would crash and I can look
at the function with viewgar. However if I make a program that uses
collect on the expression I get the same strange error and the program
exits. Is this a bug in GiNaC? Is it a bug in my software? What
could be causing this? How can I fix it?
I have attached the archive file and the source to the program that
reads the archive file. I did not give the source to the software that
originally produced it because it is a function that is dynamically
linked with another program.(GNU Octave)
In case my system configuration is important:
[ben@pcben Linux]$ ginac-config --version
0.6.4
[ben@pcben Linux]$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
[ben@pcben Linux]$ uname -a
Linux pcben 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
Thanks for any insight.
--
Ben Sapp Los Alamos National Laboratory
email: <mailto:bsapp@lanl.gov> Phone: (505)667-3277
Fax: (505)665-7920 URL: http://www.neutrino.lanl.gov/
--
GARCclasssymbolnamexThe symbolmuladdrestnumericnumber1coeffR-1 11529215046068469760 -61overall_coeffpowerbasisR1 9223372036854775808 -62exponentR1 13835058055282163712 -62The expression
J
J ;[kJ{<J;[k;[; [k
#include <ginac/ginac.h>
#include <iostream>
#include <fstream>
using namespace GiNaC;
int main()
{
archive a;
ifstream in("foobar.gar");
in >> a;
symbol x("x");
lst syms(x);
ex expr = a.unarchive_ex(syms,"The expression");
cout << "expr = " << expr << endl;
cout << expr.collect(x);
return(0);
}
Hi,
Sorry, Christian, for putting this into the list so late but I thought Ben
and others might wish to know what is going on. And sorry to all the
others for the German in it...
On Fri, 20 Oct 2000, Christian Bauer wrote:
> Ich habe jetzt eine Version gebastelt (noch nicht im CVS), die
> nicht-integer-Exponenten bei (l)degree() und coeff() als 0 ansieht, d.h:
What I was thinking of, was that ldegree returns the corresponding floor
and degree the corresponding ceiling. Is this idea somehow screwed or
does it just not matter at all?
> > e=5*x^2.0+42*x^3;
> 5*x^(2.0)+42*x^3
> > degree(e,x);
> 3
> > ldegree(e,x);
> 0
> > coeff(e,x,0);
> 5*x^(2.0)
> > coeff(e,x,2);
> 0
> > coeff(e,x,3);
> 42
> > collect(e,x);
> 5*x^(2.0)+42*x^3
[...]
> Etwas inkonsistent finde ich, das in GiNaC
>
> > is(2.0==2);
> 1
>
> wo doch 2.0 eigentlich ein inexakter Wert ist.
>
> Wohingegen
>
> > x^2.0*x^3;
> x^(5.0)
>
> in Ordnung ist.
Hmm, there is no clever way in CLN to do just that, one would have to
resort to some (trivial) RTTI-fiddling here. Is this just inconsistent or
does this lead to potential problems somewhere?
-richy.
--
Richard Kreckel
<Richard.Kreckel(a)Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
-
To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".