October 2002 - GiNaC-list

Missing namespace qualification in GiNaC 1.0.12
by Roberto Bagnara 30 Oct '02

30 Oct '02

It seems the patch below was not included in 1.0.12. Was the problem fixed in a different way? 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

GiNaC 1.0.12 "Halloween Edition" now available
by Christian Bauer 30 Oct '02

30 Oct '02

Hello! Tired of cutting faces into pumpkins, preparing poisoned cookies for your neighbours' kids, and weeding out the spam from our mailing lists? :-) Why not try GiNaC 1.0.12 which comes with these exciting features: * Fixed a bug in power::expand() that could produce invalid expressions. * The input parser no longer ignores extra data following accepted input. * Improved the CLN C-source output (integers are printed as integers, and floating point numbers include the precision). * Fixed a problem in the LaTeX-output of negative fractions. * Added print_latex() and print_csrc() to ginsh. * The sprem() function is now public. Available now from your favorite FTP server: ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Have fun, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

More Spam...
by Richard B. Kreckel 28 Oct '02

28 Oct '02

Dear folks, We apologize for the #@&*%! Spam you received through this list. Please bear with us while a solution (likely SpamAssassin) will be deployed. Meanwhile, since it hasn't been on our lists yet, I am pleased to spam you with some shameless ad about the Workshop on Open Source Computer Algebra Tuesday 21st - Thursday 23rd of May 2002 Lyon, France <http://www.lapcs.univ-lyon1.fr/~nthiery/CalculFormelLibre/workshop.html> Hurry up, in case you are interested. ¡Hasta la vista! -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 1

ginsh.exe undefined references [related to: 1) stdio.h and crtdll.dll, and 2) undef. ref. from within libreadline.a]
by Richard Haney 28 Oct '02

28 Oct '02

To: ginac-list(a)ginac.de Subject: ginsh.exe undefined references [related to: 1) stdio.h and crtdll.dll, and 2) undef. ref. from within libreadline.a] I have been working on building CLN and GiNaC for about two months now. It took me about two weeks to build CLN by running make for two or three hours at a time with occasional interventions for inspections and modifications. I have been having much more trouble with building GiNaC. ./configure takes a great deal of time to run; so I prefer to modify makefiles and adjust an alias that sets up environment variables. In order not to get confused about the many files with identical names, I keep libraries and include files in their original hierarchies, but I use several -I and -L directory flags; with this approach, occasionally a "#include" in one system header will include a header from a different package rather from the intended sibling header. (By the way, there needs to be a way to tell the preprocessor to prefer sibling headers of the invoking header rather than to always follow a fixed ordering in the search for headers.) Because of the potential for unintended includes I also have a special header directory listed first in order to explicitly "alias" specific headers when necessary using absolute pathnames. Because of using multiple header packages, this process requires very careful and painstaking manual checking to be sure appropriate headers are included; of course, I can't possibly check all such possible conflicts, but it seems reasonable to check those that seem to be a likely cause of error messages (usually via searching for significant embedded strings related to the error messages. (Similar considerations probably apply to library directories as well.) There needs to be a way to make life much simpler in this regard; if anyone knows of some excellent ways to organized multiple directories for headers (and for libraries), please let me know. It would also be nice, for example, to have a program that systematically investigates, categorizes (e.g., as a define, a prototype, a reference, or other, etc.), and perhaps even provides a dependency tree (or other graph?) for specified strings, even if the strings are "mangled" so that they are hidden from programs like window find or grep. Incidentally, the cygwin grep I have does recursive searching into subdirectories only when I specify * (all files) as the filename; if I try to limit the search to source files or header files, grep searches only the current directory; a fix for this problem would also be handy. One side-effect of my approach to organization is the prevalence of long pathnames. So I apologize in advance for having so many of them that they lengthen this message considerably. 1) Undefined references related to stdio.h and crtdll.dll: The first undefined reference is to "__imp__iob", which is apparently declared as an external in stdio.h; apparently (from comments in stdio.h) it is used for dynamic linking to 'crtdll.dll'. It seems to me that libtool and the linker do not know how to set up ginsh.exe for dynamic linking, and insist on doing static linking only via the linker. But a test compile & link using gcc to compile and link a simple C++ program that includes stdio.h and executes printf does work as expected, and Windows find finds a "__imp__iob" in the resulting executable but not in the object module. 2) The other undefined references are apparently from within various object modules in "libreadline.a'. There are lots of them. I've included only a few in the sample make output below. Incidentally, ./configure did not succeed with the final of about four libreadline tests. So I made manual modifications to config.h for libreadline (and a few other parameters). I have inserted a ${STARTFILE} at the end of the command line for linking 'ginsh.exe'; STARTFILE is defined as an environment variable--see setgccparms alias below. I have also played with changing "build_libtool_libs=no" in libtool to "build_libtool_libs=yes", but that doesn't seem to make any difference. And I have also tried using the -export-dynamic flag on the libtool command line, but libtool either objects that the flag is not valid or seems to completely ignore it altogether, depending or where in the command line I put it. I am using a cygwin/bash overlay (downloaded and installed from a nasa web site) on a Windows 98 SE platform; libreadline.a is a part of the cygwin package. CLN is version 1.1.5; GiNaC is version 1.0.9. The readline version is apparently 4.3. The bash version is 2.05b. The build requirement in cygwin's libreadline readme file lists "gcc-2.95.3-5 or newer"; so that may be a problem. I'm using gcc 2.95.2; I have a copy of the gcc 3.2 source package, which is horrendous in size. I'm trying to be very conservative about not building any more packages than I have to; package expansions and builds eat up disk space very quickly and they tend to require horrendous amounts of my time. I'm trying to keep my work portable -- on a notebook often powered from a 12v deep-cycle auxiliary lead-acid battery. When Intel finally comes out with its super-high-speed, very-low-power-consuming CPU for economical notebooks, I may then splurge and start building software packages more freely. The version tab page on the cygwin1.dll properties page says: File version: 1.3.12-cygwin-1-3-12-1 Description: Cygwin POSIX Emulation DLL API version: 0.54 BuildDate: 2002-07-06 02:16 Company Name: Red Hat Internal Name: cygwin1.dll Product Version: same as for "File version" SharedMemoryVersion: 3 I have also attempted to build libreadline from scratch, but found horrendous problems with that approach. (The fact that libreadline seems to be processed (for ginsh.exe) as far as finding undefined references in it, provides some hope that I won't have to build libreadline.) Can anyone help resolve these problems? Reference information: ********* *********** First, a snapshot of my "setgccparms" alias for setting some environment variables. *** ******* **** *********** ********* alias 'setgccparms= export CC="c:/gcc/bin/gcc" export CXX=c:/gcc/bin/c++ export CFLAGS="-g -O2" export CXXFLAGS="-g -O2" export LIBS="-lstdc++ -lmingw32 -lcln" # LIBS for linking ginsh.exe -- subject to experimental additions -- export LIBSGINSH="-lcygwin -lreadline -lhistory ${LIBS}" # standard CPPFLAGS -- includes no cygwin system headers -- export CPPFLAGS="-DDO_GINAC_ASSERT -Ic:/cygwin/home/Default/include -Ic:/gcc/include/g++-3 -Ic:/gcc/mingw32/include -Ic:/gnu/gcc_downloads--2002-08-18/mingw32-980701-4_zip/include -Ic:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/include" # Generic value for overriding in make files -- export CPPFLGEN="${CPPFLAGS}" # cygwin system include is last -- preferred approach if this works # allows cygwin dependence but least so export CPPFCYG="${CPPFLAGS} -Ic:/cygwin/usr/include" # cygwin system include is second -- # prefers cygwin headers to all other system headers -- export CPPFGINSH="-DDO_GINAC_ASSERT -Ic:/cygwin/home/Default/include -Ic:/cygwin/usr/include -Ic:/gcc/include/g++-3 -Ic:/gcc/mingw32/include -Ic:/gnu/gcc_downloads--2002-08-18/mingw32-980701-4_zip/include -Ic:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/include" # value for LDFLAGS when making libraries export LDFLIB="-s -Lc:/cygwin/home/Default/lib -Lc:/gcc/lib/gcc-lib/mingw32/2.95.2 -Lc:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw -Lc:/gnu/gcc-2.95.2-20001116_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/mingw32-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/win32api-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/egcs-1.1.1_zip/lib/gcc-lib/i386-mingw32/egcs-2.91.60 -Lc:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib" # standard LDFLAGS for executables export LDFEXE="${LDFLIB} -nostartfiles c:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw/crt2.o" # Default LDFLAGS for general use -- export LDFLAGS="${LDFEXE}" # Something to concatenate with LDFLAGS for linking ginsh -- export LDFCYGAD="-Lc:/cygwin/lib" # Something to add to link command lines for executables export STARTFILE="-nostartfiles c:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw/crt2.o"' Second, a part of the make output ****** **** ****** (For readability, a blank line is inserted between command lines and processing output. Note that rather than rerun CLN's ./configure (Ugh!) I manually placed the CLN libraries where I wanted them; so the location does not agree with 'cln-config', but presumably libtool found them anyway. Note that some 'newlines' have been re-edited for readability.) C:/cygwin/bin/sh.exe ../libtool --mode=link c:/gcc/bin/c++ -g -O2 -ggdb -Wall -pedantic -s -Lc:/cygwin/home/Default/lib -Lc:/gcc/lib/gcc-lib/mingw32/2.95.2 -Lc:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw -Lc:/gnu/gcc-2.95.2-20001116_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/mingw32-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/win32api-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/egcs-1.1.1_zip/lib/gcc-lib/i386-mingw32/egcs-2.91.60 -Lc:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib -Lc:/cygwin/lib -o ginsh.exe ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lstdc++ -lmingw32 -lcln -lcygwin -lreadline -lhistory -lstdc++ -lmingw32 -lcln -nostartfiles c:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw/crt2.o libtool: link: warning: library `c:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib/libcln.la' was moved. libtool: link: warning: library `c:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib/libcln.la' was moved. c:/gcc/bin/c++ -g -O2 -ggdb -Wall -pedantic -s -o ginsh.exe ginsh_parser.o ginsh_lexer.o -nostartfiles c:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw/crt2.o -Lc:/cygwin/home/Default/lib -Lc:/gcc/lib/gcc-lib/mingw32/2.95.2 -Lc:/gnu/mingw-20001225-1_tar_gz/usr/lib/mingw -Lc:/gnu/gcc-2.95.2-20001116_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/mingw32-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/win32api-980701-4_zip/lib -Lc:/gnu/gcc_downloads--2002-08-18/egcs-1.1.1_zip/lib/gcc-lib/i386-mingw32/egcs-2.91.60 -Lc:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib -Lc:/cygwin/lib ../ginac/.libs/libginac.a -Lc:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/lib -lcln -lcygwin -lreadline -lhistory -lmingw32 c:/gnu/source_pkgs_only/cln-1_1_5_tar_gz/cln-1.1.5/install/lib/libcln.a -L/home/Default/lib -Lc:/gnu/gcc-2.95.2-20001116_zip/lib/gcc-lib/mingw32/2.95.2 -lstdc++ ../ginac/.libs/libginac.a(input_lexer.o): In function `ginac_yylex(void)': //c/gnu/source_pkgs_only/GiNaC-1.0.9.tar_bz2/GiNaC-1.0.9/ginac/lex.yy.c:690: undefined reference to `__imp__iob' //c/gnu/source_pkgs_only/GiNaC-1.0.9.tar_bz2/GiNaC-1.0.9/ginac/lex.yy.c:693: undefined reference to `__imp__iob' ../ginac/.libs/libginac.a(input_lexer.o): In function `yy_fatal_error(char const *)': //c/gnu/source_pkgs_only/GiNaC-1.0.9.tar_bz2/GiNaC-1.0.9/ginac/lex.yy.c:1644: undefined reference to `__imp__iob' c:/cygwin/lib\libreadline.a(readline.o)(.text+0x391):readline.c: undefined reference to `sigprocmask' c:/cygwin/lib\libreadline.a(readline.o)(.text+0x39e):readline.c: undefined reference to `setjmp' c:/cygwin/lib\libreadline.a(readline.o)(.text+0x670):readline.c: undefined reference to `_imp___ctype_' c:/cygwin/lib\libreadline.a(complete.o)(.text+0x218):complete.c: undefined reference to `lstat' === segment of output deleted === c:/cygwin/lib\libreadline.a(util.o)(.text+0x46d):util.c: undefined reference to `_imp___ctype_' c:/cygwin/lib\libreadline.a(tilde.o)(.text+0x756):tilde.c: undefined reference to `getpwnam' c:/cygwin/lib\libreadline.a(tilde.o)(.text+0x83b):tilde.c: undefined reference to `endpwent' c:/cygwin/lib\libreadline.a(parens.o)(.text+0x199):parens.c: undefined reference to `select' c:\GCC\BIN\make.exe: *** [ginsh.exe] Error 1 Richard Haney __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

1 0

print_latex() bug
by Alessandro Zaccagnini 25 Oct '02

25 Oct '02

Dear all, while working with print_latex(), I found the following unexpected behaviour: the expression `p' is assigned the value 1/2-1/2*I, but then it is transformed into the following latex form: \frac{1}{2}\frac{-1}{2} i I am using version 1.0.11. Best wishes Alessandro Zaccagnini #include <iostream> #include <ginac/ginac.h> using namespace GiNaC; int main() { GiNaC::ex p; p = numeric(1)/2 + numeric(-1)/2*I; std::cout << p << " "; p.print(print_latex(std::cout)); return 0; }

2 1

Problems with ginsh
by Alessandro Zaccagnini 24 Oct '02

24 Oct '02

Dear all, I was working with ginsh and the following happened > a = 1 + x - x^2; 1+x-x^2 > b = (1+sqrt(5))/2; 1/2+1/2*sqrt(5) > subs(a,x==b); 3/2-(1/2+1/2*sqrt(5))^2+1/2*sqrt(5) > expand(%); 5/4-1/4*5 > expand(%); 5/4-1/4*5 The same thing also happens if you say >a = x^2 - x - 1; Alessandro Zaccagnini %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Dr. Alessandro Zaccagnini Dipartimento di Matematica Universita' degli Studi di Parma Via Massimo d'Azeglio 85/A 43100 Parma Italia Telefono 0521 032302 (diretto/direct) 0521 032300 (centralino/operator) Telefax 0521 032350 e-mail zaccagnini(a)prmat.math.unipr.it alessandro.zaccagnini(a)unipr.it url http://www.math.unipr.it/~zaccagni/home.html

2 1

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