November 2001 - GiNaC-devel

Bug?: (a^b).unit(a) -> SIGSEGV
by Pearu Peterson 17 Dec '01

17 Dec '01

Hi, Notice that (a^b).unit(a) leads to Segmentation fault. I have failed to track down the source of this fault in GiNaC --- I would expect that this expression should throw an exception "invalid expression in unit()", but something gets wrong elsewhere. Any ideas? Pearu For your convinience, here is a sample program: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol a("a"),b("b"); ex e = power(a,b); cout << "e="<<e<< endl; cout << "e.unit(a)="<<e.unit(a)<< endl; return 0; }

4 3

invalid expression in content|unit|...()
by Pearu Peterson 08 Dec '01

08 Dec '01

Hi, While unit-testing pyginac, I found the following inconsistency: 1) define a = symbol("a") b = symbol("b") c = constant("c") 2) observe content(2,a) -> 0 (ok) content(2*a + 4*c,a) -> 2 (ok) content(a*c,a) -> exception 'invalid expression in unit()' ?! content(a*b,a) -> b (ok) 3) similar behaviour can be observed also for other functions like unit,.. The question is: Is it possible to unify the behaviour of the relevant functions? That is, to extend them to accept other objects in addition to symbol, numeric, add, etc. Or, to raise an exception whenever there are alien object in expressions. (Though, constants should not be alien when comparing them with symbols.) My argument to consider this inconsistency as a problem is that this behaviour is confusing and could lead to difficult-to-find bugs. Thanks, Pearu

3 6

Note on pseries::power_const() method.
by Pearu Peterson 28 Nov '01

28 Nov '01

Hi again, pseries::power_const() has second argument int deg that allows negative values of deg. If one calls this method with negative deg then the line co.reserve(deg); will cause MemoryError as (unsigned)deg gets really big. My questions are: 1) Is there any sense using negative deg? If yes, then the above indicates a bug. If no, then an exception should be thrown. 2) In case negative deg is valid, then is there a reason why power_const() method needs this argument (and methods mul_const(),etc don't)? In the interface to python, I have used the following rule to find the default value for deg: If p==pseries(...) and n is integer, then deg in p.power_const(n,deg) is found as follows ldeg = abs(n * p.ldegree(p.get_var())) deg = abs(n * p.degree(p.get_var())) deg = max(ldeg,deg) + 2 With this rule, I have found that equation (p^n)^m == p^(n*m) for all integers m,n (also negative). holds (and therefore seems sensible to me). Do you see any faults in this rule? Thanks, Pearu

2 2

Bug: ex(numeric(0)).series(x==0,2).is_zero() returns incorrectly 0
by Pearu Peterson 27 Nov '01

27 Nov '01

Hi! The explanation for this bug is that pseries defines its own is_zero() method that is not used within ex::is_zero() method. As a possible solution: define basic::is_zero() (with the contents of current ex::is_zero()) and redefine ex::is_zero() to call ex::bp->is_zero(). I guess that matrix class could also have its own is_zero() method. Pearu

1 0

Release 1.0.1 just hit the shelves
by Richard B. Kreckel 22 Nov '01

22 Nov '01

Okay, before heading off to Japan with Christian we spun version 1.0.1, which fixes a few things: * Function sqrfree() handles a few more cases now. * Class relational supports real canonical ordering now (thanks to Pearu). * Handle obscene libreadline version numbers when building ginsh. This release is compatible with version 1.0.0 where compatibility is defined as on the interface and binary levels. Some computational results might differ, though, as for instance sqrfree(-y*z*x+z*x^2+z^2*x-y*z^2) will now fully factorize to z*(z+x)*(-y+x) and not get stuck with (z^2+x*z)*(x-y). Remember that we are gone for the next twelve days, so don't bother reporting bugs. IOW: We officially declare this version bug-free till then. Happy hacking -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Is relational::is_equal patch needed?
by Pearu Peterson 22 Nov '01

22 Nov '01

Hi, I have noticed that relational(a,b,==).is_equal(relational(b,a,==)) returns 0 Is this expected behaviour for GiNaC internals? I just want to know whether it is worth to write a patch such that a==b .is_equal(b==a) -> 1 a<b .is_equal(b>a) -> 1 etc. that should be implemented in the method relational::is_equal_same_type right? Regards, Pearu Pearu Peterson <pearu(a)ioc.ee>, PhD, Researcher Department of Mechanics and Applied Mathematics http://cens.ioc.ee/~pearu/ Institute of Cybernetics at Tallinn Technical University Phone: (+372) 6204168 Akadeemia Rd. 21, 12618 Tallinn ESTONIA Fax: (+372) 6204161 *** the nonvalidity of rigorous causality is necessary and not just consistently possible (Heisenberg, 1925) ***

2 3

cln?
by keith.briggs＠bt.com 22 Nov '01

22 Nov '01

Dear GiNaC people, I wanted to install ginac1 so I had to upgrade my cln to the latest version (I used older version ok). But it would not compile on my redhat6 system. (see the attachment) Any ideas? I know you are not the cln authors, but maybe you have experience with this. Thank you, Keith <<cln-probs>> Dr. Keith M. Briggs Senior Mathematician, Complexity Research, BTexact Technologies email: Keith.Briggs(a)bt.com phone: +44(0)1473 work: 641 911 home (new!): 610 517 fax: 647 410 web: www.btexact.com/people/briggsk2/ mail: Keith Briggs, Antares 2pp5, Adastral Park, Martlesham, Suffolk IP5 3RE, UK BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

2 1

bug(?): psi() Aborts
by Pearu Peterson 21 Nov '01

21 Nov '01

Hi, Notice that the following program #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { numeric x("2"); cout << "psi("<<x<<")="<<psi(x) << endl; return 0; } just Aborts when running it (when replacing psi->sin, it runs fine). Does it happen to you? I am using ginac-1.0.0 (from a week old CVS) cln-1.1.3 gmp-3.1.1, gcc version 2.95.4 20011006 (Debian prerelease) on woody debian. Any ideas what is wrong with calling psi? Btw, when when running `make ginac.html' in tutorial, it just generates ginac directory but not the file ginac.html. Pearu

2 1

relational::operator bool()
by Douglas Gregor 16 Nov '01

16 Nov '01

Hello, This is just a C++ nitpick, but operator bool() is often considered harmful because of the plethora of implicit conversions (bool->int being the worst of these implicit conversions, IMHO). I'm not suggesting that operator bool() be removed from relational, but instead replace it with a safer construct. Within the Boost C++ libraries (http://www.boost.org) we've adopted a "safe_bool" conversion using of a pointer-to-member function. The trick can be illustrated concisely: // Add to class relational private: struct dummy { void nonnull() {}; }; typedef void (dummy::*safe_bool)(); safe_bool make_safe_bool(bool cond) const { return cond? &dummy::nonnull : 0; } Then in relational::operator safe_bool() const, whereever there is a "return <bool-expression>", it should be replaced with "return make_safe_bool(<bool-expression>)". The use of the pointer-to-member function eliminates implicit conversions, but the relational class can still be used in a boolean context (since it is evaluated as "is the pointer-to-member function null?"). All meaningless operations that are allowed by a "bool" conversion except for == and != are eleminated by this "safe_bool". I can submit a patch against CVS if needed. Doug Gregor gregod(a)cs.rpi.edu

2 5

Infinity and Undefined
by Douglas Gregor 15 Nov '01

15 Nov '01

Hello all, I'm currently extending GiNaC to be used for symbolic range propagation. While the specifics of the extensions are likely not interesting to most users, I do find that I need to handle both Infinite and Undefined values in a sensible manner. I'll describe the approach I've taken thus far and would appreciate feedback. Including Infinity and Undefined within GiNaC seems to weed its way into many areas of the code. For instance, when we have two expair's x and y, we assume that if x->rest == y->rest we can combine the coefficients. Clearly this doesn't hold when we consider Infinity or Undefined, so we end up with a large number of special-case branches when we see Infinity or Undefined in an expression. This happens in quite a few places. My current approach is to defined GiNaC::constant values for Infinity and Undefined, and include functions to quickly check if an expression is the Infinity or Undefined constant. From there we just need to find all of the required special cases... Again, and feedback would be appreciated. I've only been using GiNaC for a short while, and perhaps there are tricks that could make this addition go more smoothly. Doug Gregor gregod(a)cs.rpi.edu

3 6