- GiNaC-list - ginac.de

Horrendous increase in compile times (gcc 2.95.2 vs gcc 3.2 -- MinGW versions)
by Richard Haney 15 Dec '02

15 Dec '02

I switched from gcc 2.95.2 to 3.2 -- Mingw versions -- and got a horrendous increase in compile times in subdirectory 'ginac'. Free space on my c: drive is 495 MB. (My RAM is limited to 32 MB because it seems that the circuitry for memory expansion has failed.) Is the gcc 3.2 compiler bumping hard against swapping size limits? A look at the 'system monitor' software during compilation seems to say that only 72 MB is used for swapping. Or is there something else that's causing this horrendous slowdown (like a bad compiler design in upgrading from 2.95.2 to 3.2 maybe?)? Here are a couple of tables with relevant info (listing object files with file sizes and creation times) for compiling in subdirectory ginac. Table 1 ***** * object modules created by gcc 3.2 in three continuous runs of make "--------" indicates interruption of make. (selected compile times in right hand column) (Making of power.o, operators.o, and the last ten minutes of numeric.o were done at a slower processor speed powered by an auxiliary battery. The rest of the makes were done at normal high speed using ac power; high speed is nominally 380 MHz, per user's manual; lower speed value unknown.) 1451471 Wed Dec 11 19:12:08 2002 power.o 914349 Wed Dec 11 18:17:08 2002 operators.o 1630236 Wed Dec 11 18:09:32 2002 numeric.o 1.3 hrs 1763843 Wed Dec 11 16:49:42 2002 normal.o 1.5 hrs 1351462 Wed Dec 11 15:18:02 2002 mul.o 1736244 Wed Dec 11 14:37:12 2002 matrix.o 1326684 Wed Dec 11 13:29:20 2002 inifcns_gamma.o 948098 Wed Dec 11 12:57:22 2002 inifcns_zeta.o 1675190 Wed Dec 11 12:53:10 2002 inifcns_trans.o 1415743 Wed Dec 11 11:47:16 2002 inifcns.o 1530210 Wed Dec 11 11:06:18 2002 function.o --------------------------------------------------------------------- 944331 Tue Dec 10 18:03:02 2002 fail.o 1359025 Tue Dec 10 17:58:14 2002 exprseq.o 1475200 Tue Dec 10 17:22:22 2002 expairseq.o --------------------------------------------------------------------- 885881 Tue Dec 10 14:56:32 2002 expair.o 3.2 min 967914 Tue Dec 10 14:53:18 2002 ex.o 8.5 1055734 Tue Dec 10 14:44:48 2002 constant.o 16.2 1124770 Tue Dec 10 14:28:34 2002 basic.o 20.3 1374322 Tue Dec 10 14:08:18 2002 archive.o 30.7 1203797 Tue Dec 10 13:37:38 2002 add.o Table 2 ***** * Object modules created by gcc 2.95.2 with continuous operation of make (selected compile times in right hand column) (normal high processor speed using ac power; high speed is nominally 380 MHz, per user's manual.) 274186 Tue Oct 08 17:25:36 2002 operators.o 1820796 Tue Oct 08 17:24:36 2002 numeric.o 7.1 min 1792847 Tue Oct 08 17:17:32 2002 normal.o 5.5 min 894707 Tue Oct 08 17:12:00 2002 mul.o 1581044 Tue Oct 08 17:10:10 2002 matrix.o 839184 Tue Oct 08 17:07:32 2002 inifcns_gamma.o 307886 Tue Oct 08 17:06:04 2002 inifcns_zeta.o 1572996 Tue Oct 08 17:05:06 2002 inifcns_trans.o 1034273 Tue Oct 08 17:01:40 2002 inifcns.o 1155709 Tue Oct 08 16:59:14 2002 function.o 188153 Tue Oct 08 16:57:44 2002 fail.o 744889 Tue Oct 08 16:57:02 2002 exprseq.o 1094132 Tue Oct 08 16:56:00 2002 expairseq.o 105948 Tue Oct 08 16:54:24 2002 expair.o 0.7 min 257110 Tue Oct 08 16:53:42 2002 ex.o 0.7 min 378665 Tue Oct 08 16:52:58 2002 constant.o 1.0 min 479942 Tue Oct 08 16:51:58 2002 basic.o 1.0 min 972535 Tue Oct 08 16:50:58 2002 archive.o 1.0 min 561407 Tue Oct 08 16:49:58 2002 add.o ================== Here is also a summary of similar results for compiling CLN modules: Statistics for gcc 3.2 v 2.95.2 for CLN object modules ********** *** *** ****** *** ****** ******* gcc 2.95.2 compilation of cln modules in subdir src: ****** Average compile time for the second through 27th module is 19 seconds. Average object module size for the first 27 modules is 18,896 bytes. Average object module size for all 855 modules is 67,125 bytes. -------------------------------- gcc 3.2 compilation of cln modules in subdir src: *** Average compile time for the second through 27th module is 2.3 minutes. Average object module size for the first 27 modules is 254,008 bytes. Average object module size for all 855 modules is 198,708 bytes. What can I do to get CLN & GiNaC built reasonably well? I again tried to make libreadline with gcc 2.95.2 (using new things I've learned) because 2.95.2 seems at present to be the best bet, but I still run into problems. It seems I need a new set of header files (and maybe gcc 2.95.2 libraries) or, preferably, a gcc 2.95.2 libreadline.a for win32 (i.e., MinGW). That would allow me to continue with using gcc 2.95.2. Richard Haney __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

why is GiNaC::symbol commutative??
by smilauer＠volny.cz 03 Dec '02

03 Dec '02

Hello, subject explains it all. I would like to use symbols to represent matrices. Obvious solution (replacing symbols via some_ex.sub(some_symbol==some_matrix) does not work for multiplication of matrices. Other ways to do it? Thanks. Vaclav. (If I understand it right, upon replacement of one matrix, one has matrix*symbol; symbol is supposed to be a scalar, so we have commutative multiplication; then the other symbol is also substituted for a matrix, so one gets exception "non-commutative scalar".)

2 1

Automatic evaluation/simplification
by Roberto Bagnara 13 Nov '02

13 Nov '02

Yes, the FAQ says it is completely automatic. However, is there a way to switch it off? Forgive me for the very imprecise question. The situation is as follows: we have some monster expressions where we need to substitute a few thousands of symbol's occurrences with something else. We did that by implementing our own recursive tree traversal. However, we estimate that more than 80% of the time is spent in attempted simplifications by GiNaC (which we know are deemed to fail). Is there any way to implement this substitution process so as to avoid this big overhead? Thanks in advance 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

Spam filter installed
by Christian Bauer 11 Nov '02

11 Nov '02

Hello! SpamAssassin 2.20 is now installed on all GiNaC and xloops mailing lists, so the amount of advertisements relayed over the lists should decrease considerably. Since SpamAssassin uses a set of heuristics to identify spam, there's of course still a chance that some of it may get through. There's also the chance that valid mail will accidentally be classified as spam. In any case, all potential spam mails will be reviewed by us, and valid messages will be resent to the lists, so there shouldn't be any information loss. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

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