- GiNaC-list - ginac.de

GiNaC parser problems
by Roberto Bagnara 24 Oct '02

24 Oct '02

Hi there, implementing interactive GiNaC programs is made extremely painful by the fact that GiNaC's parser accepts too much. This claim can be checked with the attached program derived from an example in the tutorial. Basically, stuff at the end of the string sometimes is accepted even if nonsensical. Moreover, once a well-formed string has been parsed, things tend to be accepted anyway. $ a.out Enter an expression containing 'x': x.13 put what you want here The derivative of x with respect to x is 1. $ a.out Enter an expression containing 'x': x. The derivative of 0 with respect to x is 0. Enter an expression containing 'x': x.13 put what you want here The derivative of x with respect to x is 1. Again: $ a.out Enter an expression containing 'x': 0 The derivative of 0 with respect to x is 0. Enter an expression containing 'x': log(|x|) The derivative of 0 with respect to x is 0. Enter an expression containing 'x': log(|x|+put anything here) The derivative of 0 with respect to x is 0. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it #include <iostream> #include <string> #include <stdexcept> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { while (true) { symbol x("x"); string s; cout << "Enter an expression containing 'x': "; getline(cin, s); if (!cin) return 0; try { ex e(s, lst(x)); cout << "The derivative of " << e << " with respect to x is "; cout << e.diff(x) << ".\n"; } catch (exception &p) { cerr << p.what() << endl; } } }

2 1

Can't find CLN
by Johannes Strömberg 14 Oct '02

14 Oct '02

Hi, After compiling and installing CLN I try to run ./configure on GiNaC but it says it cannot find a CLN installation. What have I missed? /Johannes

2 2

Now seriously: what is a polynomial?
by Roberto Bagnara 13 Oct '02

13 Oct '02

Dear all, this message is a first of a small series where we try to summarize our difficulties with GiNaC and its (lack of) documentation. As a general remark, several concepts are defined only through examples whereas formal definitions would help greatly. In this message we concentrate on one concept that is central to our application: the concept of "polynomial". Here are our sources of information: 1) The tutorial: a bunch of examples are presented that, however do not clarify the general idea. 2) The method `info(info_flags::polynomial)' should constitute, we used to believe, the very formal specification of the notion of "being a polynomial". 3) The message by Christian Bauer (March 7th, 2002, see http://www.ginac.de/lists/ginac-list/msg00232.html) "But this is the intended behavior: If e is of the form e = sum(i=n1..n2, a_i * x^i) with n1, n2 integer and expressions a_i that satisfy has(a_i, x) == false, then degree(e, x) and ldegree(e, x) are well defined and accurate. I think this should even cover cases like degree(sin(y)^3-sin(y),sin(y)) which is guaranteed to return 3." The problem is that, while 1 is inconclusive, 2 and 3 (with the correction replacing "integer" by "nonnegative integer") conflict with each other. Let us consider the expression e = sqrt(2)*x. Since, clearly, has(sqrt(2), x) == false, `e' is a polynomial for 3. But, since e.info(info_flags::polynomial) == false, `e' is not a polynomial according to 2. The point here is to decide _exactly_ for which class of expressions are the functions degree(), ldegree(), coeff(), lcoeff(), tcoeff(), expand(), collect(), quo(), rem(), prem(), gcd(), lcm(), sqrfree() and so forth guaranteed to work. All the best Roberto Bagnara Alessandro Zaccagnini Enea Zaffanella Tatiana Zolo /***************************************************************************/ #include <ginac/ginac.h> #include <iostream> using namespace GiNaC; using namespace std; int main() { symbol x("x"); ex coeff = sqrt(ex(2)); ex e = coeff*x; cout << (e.info(info_flags::polynomial) ? "true" : "false") << endl; cout << (!has(coeff, x) ? "true" : "false") << endl; return 0; } /***************************************************************************/ -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

3 3

Why GPL and not LGPL?
by Johannes Strömberg 08 Oct '02

08 Oct '02

Hi, Why is GiNaC released under GPL and not under LGPL since it is a library system? /Johannes

3 3

Educative sofware using Ginac
by Jean-Pierre Branchard 06 Oct '02

06 Oct '02

"Ginette" is a free software project for GNU/Linux system. It was made in order to help the teenagers in solving equations and linear systems. "Ginette" read the equations from a text file which was written by the teacher. For each equation, the student have to choose between few operations in a combo-box. Theses operations will bring him gradually to the equation's solution. For example, to solve the equation "2x+3=-5x+4", the student can choose to substrac 3 from the two parts of the equation. The software's answer will be "2x=-5x+1" etc... This symbolic computation is based on the library "GINAC". The interface for the user is written with GTK-1.2. I use GTK rather GTKmm so as to make a version of "Ginette" for the MS-Windows system, but I need some help to use Ginac with MS Windows. You can find "ginette" here : http://savannah.nongnu.org/download/ginette Jean-Pierr.branchard(a)ac-grenoble.fr

1 0

Exceptions.
by Tatiana Zolo 03 Oct '02

03 Oct '02

Hi. I have problems in understanding GiNaC policy regarding the choice of exceptions thrown. The operator `operator/' defined on objects of the class `numeric' throws a `runtime_error' in the case of a division by zero. In contrast, the `operator/' defined on objects of the class `ex' throws a `logic_error' in the case of a division by zero. Why is there such a difference? According to the standard, the exception `logic_error' should be used when errors could have been detected before program execution: I thus believe that a `runtime_error' should be thrown even in the case of an `ex' object. The same argument hold for the exception thrown by `power': logic_error: power::eval(): division by zero. Thanks Tatiana Zolo

2 1

Behavior of numeric::to_int() and numeric::to_long()
by Roberto Bagnara 01 Oct '02

01 Oct '02

These methods, and the corresponding functions taking the argument as a const numeric& parameter, when something goes wrong print a line of the form Not a 32-bit integer: -9223372028264841216 on cerr and exit the program. Wouldn't throwing a suitable standard exception (like std::domain_error) be a better option? All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 8

Last in this series: behavior of irem()
by Roberto Bagnara 01 Oct '02

01 Oct '02

The function numeric irem(const numeric &a, const numeric &b) prints "Division by zero." and exits when b is zero. As in all the other cases reported, this makes it more difficult to write robust software. Of course, we can check b before calling irem() (and we are doing it) but this impedes performance for no reason, since the test on b must be re-done anyway in order to decide whether to print the error message and exit. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 1

Behavior of numeric::is_prime()
by Roberto Bagnara 01 Oct '02

01 Oct '02

In an attempt to invent documentation for the GiNaC facilities we use, we came across the following inconsistency in the behavior of the method bool numeric::is_prime(void) const and the function bool is_prime(const numeric &x), whereby exit(1) is called (via cl_abort()) if the number to be tested is a non-positive integer. I believe is_prime() should return false in this case, as it does for, e.g., -2/7, 2/7, 3*I, and 2.8943657489. All the best Roberto P.S. I am not including a patch since this issues may be dealt with either in CLN (which I believe is the better option) or in GiNaC. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 1

Missing namespace qualification
by Roberto Bagnara 29 Sep '02

29 Sep '02

The patch below should be applied to GiNaC 1.0.11. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -c -d -r1.1.1.1 function.h *** ginac/function.h 29 Sep 2002 13:26:57 -0000 1.1.1.1 --- ginac/function.h 29 Sep 2002 14:02:48 -0000 *************** *** 416,422 **** } #define is_ex_the_function(OBJ, FUNCNAME) \ ! (GiNaC::is_exactly_a<GiNaC::function>(OBJ) && GiNaC::ex_to<GiNaC::function>(OBJ).get_serial() == function_index_##FUNCNAME) } // namespace GiNaC --- 416,422 ---- } #define is_ex_the_function(OBJ, FUNCNAME) \ ! (GiNaC::is_exactly_a<GiNaC::function>(OBJ) && GiNaC::ex_to<GiNaC::function>(OBJ).get_serial() == GiNaC::function_index_##FUNCNAME) } // namespace GiNaC

2 1