From markus.nullmeier at urz.uni-heidelberg.de Fri Feb 1 18:44:54 2002 From: markus.nullmeier at urz.uni-heidelberg.de (Markus Nullmeier) Date: Fri, 1 Feb 2002 18:44:54 +0100 (CET) Subject: Alternative bernoulli(const numeric &) In-Reply-To: from "Richard B. Kreckel" at "Jan 23, 2002 11:56:13 am" Message-ID: <200202011744.SAA42070@aixterm7.urz.uni-heidelberg.de> Now the point I was going to make is simply to update the CLN documentation. As for the debatable optimization I made in the posted patches, I totally agree to use cl_value_len there. > > weird (hypothetical?) system with alignment = 8 and sizeof(long) = > > "32 bits" will break the documented behaviour :-/ well, that would mean cl_value_len = 29 insted of the normal cl_value_len = 30 for 32 bit architectures and cl_value_len = 32 for 64 bit architectures, if my interpretation of CLN's header didn't fail (but such failure is quite likely anyway...): 4-byte alignment eats 2 bits, 8-byte alignment eats 3 bits off cl_value_len, at least for 32 bit architectures. And, the headers get the architecture idea from something like sizeof(long) in intparam.h: e.g. #define long_bitsize 32 (made by autoconf, I guess). > Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would I don't know if (Pointer size) != sizeof(long) will work for CLN's headers. I was thinking of Pointer size = 4 and alignment = 8. Maybe I'm a fool and anybody will prove that there were never such systems and never will be... > have to be changed... What do you say is gonna break there? (BTW, the The only thing that would break on these non-existing (?) system is the "quick conversion" from C++'s int to CLN's cl_I, for values of e. g. 2^28, contrary to the documentation. Therefore IMHO CLN's documetation could be updated to speak of 2^(cl_value_len-1) instead of 2^29. Anybody still reading? Markus From kreckel at thep.physik.uni-mainz.de Fri Feb 1 19:38:14 2002 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Fri, 1 Feb 2002 19:38:14 +0100 (CET) Subject: Alternative bernoulli(const numeric &) In-Reply-To: <200202011744.SAA42070@aixterm7.urz.uni-heidelberg.de> Message-ID: Hi, Markus! On Fri, 1 Feb 2002, Markus Nullmeier wrote: > Now the point I was going to make is simply to update the CLN > documentation. Maybe. I'll try to think up a formulation. > As for the debatable optimization I made in the > posted patches, I totally agree to use cl_value_len there. > > > > weird (hypothetical?) system with alignment = 8 and sizeof(long) = > > > "32 bits" will break the documented behaviour :-/ > > well, that would mean cl_value_len = 29 insted of the normal > cl_value_len = 30 for 32 bit architectures and > cl_value_len = 32 for 64 bit architectures, > > if my interpretation of CLN's header didn't fail (but such failure is > quite likely anyway...): 4-byte alignment eats 2 bits, 8-byte alignment > eats 3 bits off cl_value_len, at least for 32 bit architectures. No, your interpretation did not fail, at least as long as you refer to the value of cl_word_alignment. See below... > And, > the headers get the architecture idea from something like sizeof(long) > in intparam.h: e.g. #define long_bitsize 32 (made by autoconf, I guess). Yes, intparam.h is generated by compiling and running intparam.cc while running configure. > > Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would > > I don't know if (Pointer size) != sizeof(long) will work for CLN's > headers. Okay, just for the record: I have never heard of any 64-bit machine which does not adhere to the LP64-model. Has anybody else? > I was thinking of Pointer size = 4 and alignment = 8. Maybe I'm > a fool and anybody will prove that there were never such systems and > never will be... Well, we should see if anybody really comes up with something thus pervert and just fix the header then... ...by dropping the macro cl_word_alignment into as usual. I am talking about lying, here. We can simply tell CLN the alignment is actually 4. Nothing is spoiled if the system never sets this additional bit in the malloc'ed address. They can even make it 12, 16, 20 or 128 if they think this is a bright idea, as long as the last two bits are not set. ;-) Sounds reasonable? > > have to be changed... What do you say is gonna break there? (BTW, the > > The only thing that would break on these non-existing (?) system is the > "quick conversion" from C++'s int to CLN's cl_I, for values of e. g. 2^28, > contrary to the documentation. Therefore IMHO CLN's documetation > could be updated to speak of 2^(cl_value_len-1) instead of 2^29. OTOH, if you compute with int variables you need to be careful in C, anyways: int x = 1000000; int y = x*x; is not a mistake but anybody who expects y to be equal to 1000000000000 then is naive, at best. This limit just happens to be pushed down from 2^32 to 2^29. > Anybody still reading? Markus Even answering! -richy. -- Richard B. Kreckel From bagnara at cs.unipr.it Sat Feb 2 07:34:12 2002 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Sat, 02 Feb 2002 07:34:12 +0100 Subject: Annoying warning Message-ID: <3C5B8864.9010302@cs.unipr.it> Dear all, there is a warning about an unused parameter due to line 84 in basic.h (GiNaC 1.0.5): virtual void destroy(bool call_parent) { } Having seen the warning a million times I thought it was better to report it ;-) 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 at cs.unipr.it From cbauer at student.physik.uni-mainz.de Sat Feb 2 12:49:56 2002 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Sat, 2 Feb 2002 12:49:56 +0100 Subject: Annoying warning In-Reply-To: <3C5B8864.9010302@cs.unipr.it> References: <3C5B8864.9010302@cs.unipr.it> Message-ID: <20020202124956.A24605@student.physik.uni-mainz.de> Hi! On Sat, Feb 02, 2002 at 07:34:12AM +0100, Roberto Bagnara wrote: > there is a warning about an unused parameter due to > line 84 in basic.h (GiNaC 1.0.5): > > virtual void destroy(bool call_parent) { } But the parameter _is_ unused... :-/ Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From frink at thep.physik.uni-mainz.de Sat Feb 2 22:56:38 2002 From: frink at thep.physik.uni-mainz.de (Alexander Frink) Date: Sat, 2 Feb 2002 22:56:38 +0100 (CET) Subject: Annoying warning In-Reply-To: <3C5B8864.9010302@cs.unipr.it> Message-ID: On Sat, 2 Feb 2002, Roberto Bagnara wrote: > there is a warning about an unused parameter due to > line 84 in basic.h (GiNaC 1.0.5): > > virtual void destroy(bool call_parent) { } > > Having seen the warning a million times I thought > it was better to report it ;-) Which compiler/switches do you use? Maybe __attribute__ ((unused)) helps (for gcc 3.x). Alex -- Alexander Frink E-Mail: Alexander.Frink at Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany From cbauer at student.physik.uni-mainz.de Sun Feb 3 13:45:04 2002 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Sun, 3 Feb 2002 13:45:04 +0100 Subject: Annoying warning In-Reply-To: References: <3C5B8864.9010302@cs.unipr.it> Message-ID: <20020203134504.A31948@student.physik.uni-mainz.de> Hi! On Sat, Feb 02, 2002 at 10:56:38PM +0100, Alexander Frink wrote: > > there is a warning about an unused parameter due to > > line 84 in basic.h (GiNaC 1.0.5): > > Which compiler/switches do you use? > Maybe __attribute__ ((unused)) helps (for gcc 3.x). I'd suggest -Wno-unused-parameter. Unused parameters are common in C++, with all the overloaded functions. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From frink at thep.physik.uni-mainz.de Sun Feb 3 23:36:38 2002 From: frink at thep.physik.uni-mainz.de (Alexander Frink) Date: Sun, 3 Feb 2002 23:36:38 +0100 (CET) Subject: Annoying warning In-Reply-To: <20020203134504.A31948@student.physik.uni-mainz.de> Message-ID: On Sun, 3 Feb 2002, Christian Bauer wrote: > I'd suggest -Wno-unused-parameter. Unused parameters are common in C++, > with all the overloaded functions. That's the reason why I have never seen a compiler complaining about it. Nevertheless -Wno-unused-parameter also would disable the warning in cases where it might be useful. Alex -- Alexander Frink E-Mail: Alexander.Frink at Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany From kreckel at thep.physik.uni-mainz.de Mon Feb 4 21:04:04 2002 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Mon, 4 Feb 2002 21:04:04 +0100 (CET) Subject: FAQ Message-ID: Hi, Our FAQ [1] was giving the impression that tree-traversals for complex operations are best being written as functions that recursively call themselves and contain lots of silly little ifs that distinguish between the different object types. This was rubbish. I have polished up an old example (an actual prototype of a simplifier in a certain domain) and rewritten the items "How do I simplify things like sin^2+cos^2 to 1?" and "How do I write a tree-traversal algorithm?" from scratch to take a more elegant and more powerful point of view. If (after careful study, please) people find something unclear therein or even actual errors, I would very much like to hear about that. I am confident that people writing applications in GiNaC will benefit greatly from these these two rewritten sections. For the curious, the old FAQ is still available [2]. enjoy! -richy. [1] [2] -- Richard B. Kreckel From keith.briggs at bt.com Thu Feb 14 16:27:56 2002 From: keith.briggs at bt.com (keith.briggs at bt.com) Date: Thu, 14 Feb 2002 15:27:56 -0000 Subject: ginsh compile problem Message-ID: ginac-1.0.5 fails to compile ginsh using: redhat 6.0 gcc-3.0.3 cln-1.1.4 readline-2.2.1-5 > > Making all in ginsh > > make[2]: Entering directory `/home/kbriggs/GiNaC-1.0.5/ginsh' > > sed -n -f ./ginsh_fcn_help.sed ginsh_fcn_help.h > > sed -n -f ./ginsh_op_help.sed ginsh_op_help.h > > source='ginsh_parser.cc' object='ginsh_parser.o' libtool=no \ > > depfile='.deps/ginsh_parser.Po' tmpdepfile='.deps/ginsh_parser.TPo' \ > > depmode=gcc3 /bin/sh ../depcomp \ > > /usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac > > -DIN_GINAC -I/usr/local/include -g -O2 -c -o ginsh_parser.o `test -f > > ginsh_parser.cc || echo './'`ginsh_parser.cc > > /usr/include/readline/readline.h: In function `char** > fcn_completion(const > > char*, int, int)': > > /usr/include/readline/readline.h:232: too many arguments to function > `char** > > > > completion_matches()' > > ginsh_parser.yy:769: at this point in file > > /usr/include/readline/readline.h:232: too many arguments to function > `char** > > > > completion_matches()' > > ginsh_parser.yy:779: at this point in file > > make[2]: *** [ginsh_parser.o] Error 1 > > make[2]: Leaving directory `/home/kbriggs/GiNaC-1.0.5/ginsh' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/kbriggs/GiNaC-1.0.5' > > make: *** [all] Error 2 > > > > Dr. Keith M. Briggs > > Senior Mathematician, Complexity Research, BTexact Technologies > > > > email: Keith.Briggs at 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 > > From bagnara at cs.unipr.it Wed Feb 20 08:55:12 2002 From: bagnara at cs.unipr.it (Roberto Bagnara) Date: Wed, 20 Feb 2002 08:55:12 +0100 Subject: ginac.m4 and cln.m4 Message-ID: <3C735660.4060300@cs.unipr.it> Hi there, there are problems with ginac.m4 and cln.m4 with autoconf 2.52 and following (the nature of the problems and their cure is described in autoconf's documentation). Please find enclosed a patch that solves everything. 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 at cs.unipr.it diff -rcp2N old/cln.m4 new/cln.m4 *** old/cln.m4 Wed Feb 20 08:43:47 2002 --- new/cln.m4 Wed Feb 20 08:42:33 2002 *************** dnl AC_PATH_CLN([MINIMUM-VERSION, [ACTIO *** 11,15 **** dnl Test for installed CLN library, and define CLN_CPPFLAGS and CLN_LIBS dnl ! AC_DEFUN(AC_PATH_CLN, [dnl dnl Get the cppflags and libraries from the cln-config script --- 11,15 ---- dnl Test for installed CLN library, and define CLN_CPPFLAGS and CLN_LIBS dnl ! AC_DEFUN([AC_PATH_CLN], [dnl dnl Get the cppflags and libraries from the cln-config script diff -rcp2N old/ginac.m4 new/ginac.m4 *** old/ginac.m4 Wed Feb 20 08:43:17 2002 --- new/ginac.m4 Wed Feb 20 08:42:33 2002 *************** *** 8,15 **** # Shamelessly stolen from Owen Taylor ! dnl AM_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS dnl ! AC_DEFUN(AM_PATH_GINAC, [dnl dnl Get the cppflags and libraries from the ginac-config script --- 8,15 ---- # Shamelessly stolen from Owen Taylor ! dnl AC_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS dnl ! AC_DEFUN([AC_PATH_GINAC], [dnl dnl Get the cppflags and libraries from the ginac-config script From kreckel at thep.physik.uni-mainz.de Wed Feb 20 16:26:22 2002 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Wed, 20 Feb 2002 16:26:22 +0100 (CET) Subject: ginac.m4 and cln.m4 In-Reply-To: <3C735660.4060300@cs.unipr.it> Message-ID: Hi, On Wed, 20 Feb 2002, Roberto Bagnara wrote: > there are problems with ginac.m4 and cln.m4 with autoconf 2.52 and following > (the nature of the problems and their cure is described in autoconf's documentation). > Please find enclosed a patch that solves everything. [...] > ! dnl AM_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) > dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS > dnl > ! AC_DEFUN(AM_PATH_GINAC, > [dnl > dnl Get the cppflags and libraries from the ginac-config script > --- 8,15 ---- > # Shamelessly stolen from Owen Taylor > > ! dnl AC_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) > dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS > dnl > ! AC_DEFUN([AC_PATH_GINAC], > [dnl > dnl Get the cppflags and libraries from the ginac-config script Well, but why rename it from AM_PATH_GINAC to AC_PATH_GINAC? This breaks things! Am I right supposing there is no urgent need to do this renaming? Regards -richy. -- Richard B. Kreckel