April 2004 - GiNaC-devel

Link Failure with 1.2.1 and Mac OS X 10.3.3
by Gregory Wright 26 Apr '04

26 Apr '04

Hi, The latest still fails to link on Mac OS 10.3.3. Build log is below. Any suggestions? Best Wishes, Greg if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -DIN_GINAC -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT ginsh_lexer.o -MD -MP -MF ".deps/ginsh_lexer.Tpo" \ -c -o ginsh_lexer.o `test -f 'ginsh_lexer.cc' || echo './'`ginsh_lexer.cc; \ then mv -f ".deps/ginsh_lexer.Tpo" ".deps/ginsh_lexer.Po"; \ else rm -f ".deps/ginsh_lexer.Tpo"; exit 1; \ fi /bin/sh ../libtool --mode=link g++ -g -O2 -L/opt/local/lib -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lreadline -lncurses -L/opt/local/lib -lcln -lgmp mkdir .libs g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o -Wl,-bind_at_load -L/opt/local/lib ../ginac/.libs/libginac.dylib -lreadline -lncurses /opt/local/lib/libcln.dylib -lstdc++ /opt/local/lib/libgmp.dylib ld: warning multiple definitions of symbol _PC /opt/local/lib/libreadline.dylib(terminal.so) definition of _PC /usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Target com.apple.build returned: shell command "cd "/Users/gwright/src/darwinports/dports/math/GiNaC/work/GiNaC-1.2.1" && make all" returned error 2 Command output: ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Warning: the following items did not execute (for GiNaC): com.apple.build ranger>

2 1

GiNaC 1.2.1 now available
by Christian Bauer 23 Apr '04

23 Apr '04

Hello! GiNaC 1.2.1 is now available! The changes are: - Fixed infinite recursion in atan2_evalf() and improved atan2_eval(). - Added automatic evaluations for trigonometric functions with negative arguments (e.g. sin(-2) -> -sin(2)). - Fixed a static initialization order goof-up. - Fixed various bugs in series expansion. If you had problems using GiNaC 1.2 on certain platforms because you were getting segmentation faults all the way, this release should solve the issue. You can download GiNaC 1.2.1 as always from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Bye, Jens and Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0

Link failure on OS X 10.3.3
by Gregory Wright 23 Apr '04

23 Apr '04

Hi, While building 1.2.0 on Mac OS X 10.3.3 (Panther) I had a link error. The underlying CLN is version 1.1.6 built with gmp 4.1.2. The compiler is ranger> gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The error is below. The multiply defined symbols are harmless, but the undefined symbols are the problem. Is this perhaps some link-ordering issue? Does anyone have any ideas? Please cc: to me directly as I am not subscribed to the list yet. Thanks. Best Wishes, Greg Wright if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -DIN_GINAC -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT ginsh_lexer.o -MD -MP -MF ".deps/ginsh_lexer.Tpo" \ -c -o ginsh_lexer.o `test -f 'ginsh_lexer.cc' || echo './'`ginsh_lexer.cc; \ then mv -f ".deps/ginsh_lexer.Tpo" ".deps/ginsh_lexer.Po"; \ else rm -f ".deps/ginsh_lexer.Tpo"; exit 1; \ fi /bin/sh ../libtool --mode=link g++ -g -O2 -L/opt/local/lib -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lreadline -lncurses -L/opt/local/lib -lcln -lgmp mkdir .libs g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o -Wl,-bind_at_load -L/opt/local/lib ../ginac/.libs/libginac.dylib -lreadline -lncurses /opt/local/lib/libcln.dylib -lstdc++ /opt/local/lib/libgmp.dylib ld: warning multiple definitions of symbol _PC /opt/local/lib/libreadline.dylib(terminal.so) definition of _PC /usr/lib/libncurses.dylib(lib_tputs.o) definition of _PC ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Target com.apple.build returned: shell command "cd "/Users/gwright/src/darwinports/dports/math/GiNaC/work/GiNaC-1.2.0" && make all" returned error 2 Command output: ld: warning multiple definitions of symbol _BC /opt/local/lib/libreadline.dylib(terminal.so) definition of _BC /usr/lib/libncurses.dylib(lib_termcap.o) definition of _BC ld: warning multiple definitions of symbol _UP /opt/local/lib/libreadline.dylib(terminal.so) definition of _UP /usr/lib/libncurses.dylib(lib_termcap.o) definition of _UP ld: Undefined symbols: __GLOBAL__I_cl_module__cl_C_ring__firstglobalfun __GLOBAL__I_cl_module__cl_DF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_FF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_GV_I__firstglobalfun __GLOBAL__I_cl_module__cl_GV_number__firstglobalfun __GLOBAL__I_cl_module__cl_I_ring__firstglobalfun __GLOBAL__I_cl_module__cl_LF_globals__firstglobalfun __GLOBAL__I_cl_module__cl_MI__firstglobalfun __GLOBAL__I_cl_module__cl_RA_ring__firstglobalfun __GLOBAL__I_cl_module__cl_R_ring__firstglobalfun __GLOBAL__I_cl_module__cl_SV_number__firstglobalfun __GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun __GLOBAL__I_cl_module__cl_UP__firstglobalfun __GLOBAL__I_cl_module__cl_UP_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_ieee__firstglobalfun __GLOBAL__I_cl_module__cl_no_ring__firstglobalfun __GLOBAL__I_cl_module__cl_prin_globals__firstglobalfun __GLOBAL__I_cl_module__cl_random_def__firstglobalfun __GLOBAL__I_cl_module__cl_st_null__firstglobalfun __GLOBAL__I_cl_module__cl_symbol__firstglobalfun make[2]: *** [ginsh] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

1 0

series expansion of powers.
by Chris Dams 21 Apr '04

21 Apr '04

Hello, Recently I had to find the power series to 11th order of the fifth power of a polynomial of degree 11 containing all kinds of symbols. The thing that was raised to the fifth power had 139 terms. The point of course is that in this case you do not want to have the full expansion of this power because it is way too large, takes too much time, and not necesary to find the answer. However, using the series method falls back on basic::series and this uses expand() internally. The conclusion would be that power::series is a bit to eager to use basic::series. Changing the line if (!must_expand_basis && !exponent.info(info_flags::negint)) that occurs in power::series into if (!must_expand_basis && !exponent.info(info_flags::negint) && !is_a<add>(basis)) makes this calculation finish within the second. Bye, Chris Dams

2 1

series taking too looooooong.
by Chris Dams 19 Apr '04

19 Apr '04

Hello, I found out that if I make the series expansion of a multiplication that has somewhere in it a factor to a rather large power (say 8), determining the lowest order of that takes very long. For instance, determinging the lowest order of b0^(-10)*(-2*b0^(-7)*log(-b0^(-2)*b1*recs)*b1^3*recs^4-b0^(-5)*log(-b0^(-2)*b1*recs)^2*b1^2*recs^3+b0^(-5)*b1^2*recs^3+b0^(-7)*log(-b0^(-2)*b1*recs)^3*b1^3*recs^4+b0^(-3)*log(-b0^(-2)*b1*recs)*b1*recs^2+3*b0^(-6)*b2*log(-b0^(-2)*b1*recs)*b1*recs^4-1/2*b0^(-7)*b1^3*recs^4-b0^(-4)*b2*recs^3+1/2*b0^(-5)*recs^4*b3-b0^(-1)*recs-b0^(-5)*log(-b0^(-2)*b1*recs)*b1^2*recs^3+5/2*b0^(-7)*log(-b0^(-2)*b1*recs)^2*b1^3*recs^4)^8*b1^9 with respect to the variable recs takes a few seconds on my pentium 1.8 GHz. The attached patch should make this much faster by determining the lowest order of the base and simply multiplying it with the exponent. Bye, Chris

2 1

expansion of log
by Chris Dams 19 Apr '04

19 Apr '04

Hello all, The patch I sent last friday turned up in the source. That's the good part, but unfortunately at the wrong spot. The line const ex newarg = ex_to<pseries>((arg/coeff).series(rel, order+n, options)).shift_exponents(-n).convert_to_poly(true); should appear after the patch. If it comes before, the patch does not solve anything. Bye, Chris Dams

2 2

Re: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP
by Johannes Brunen 19 Apr '04

19 Apr '04

Hi Christian, I second your doubts. I think that the problem is a little more hidden. After I added some print statements into the library_init's constructor I could confirm that this function is called before the call of function_options::initialize() function, as it was intended. However, the initilaization of the const _num0 reference happens at some time later. Therefore it is undefined at the point of usage in the ex::construct_from_int(int i) call from function_options::initialize(). At the point of _num0 initialization the counter has already a value of count == 33. I still think that the problem lies in the initialization order of statics defined in different translation units. Unfortunately, I couldn't find an exact explanation of my guess. With best regards Johannes

5 5

patch for expansion of log.
by Chris Dams 17 Apr '04

17 Apr '04

Hello, I found out that trying to calculate log(a*x+b*x*x*log(x)).series(x==0,3) does not terminate. This is because in the function the argument has a pole even if a log(a*x) is subtracted. The attached patch should solve this. With this patch the result of the calculation is (log(x*a))+(a^(-1)*b*log(x))*x+(-1/2*a^(-2)*b^2*log(x)^2)*x^2+Order(x^3) as expected. Have a nice weekend, Chris Dams

2 1

None
by Allan E. Johannesen 15 Apr '04

15 Apr '04

I will be out of the office until Monday, April 26 I have received your message, but if you require faster action, please contact the help desk. helpdesk(a)wpi.edu or (508)831-5888 For network probems, you might email netops(a)wpi.edu For telephone problems, you might email telecom(a)wpi.edu For UNIX problems, you might email root(a)wpi.edu

1 0

Re: error in object.h (CLN) ?
by fausap＠libero.it 09 Apr '04

09 Apr '04

---------- Initial Header ----------- >From : owner-ginac-devel(a)thep.physik.uni-mainz.de To : "GiNaC developers list" ginac-devel(a)thep.physik.uni-mainz.de Cc : "Fausto Saporito" fausap(a)libero.it Date : Mon, 5 Apr 2004 21:38:22 +0200 (CEST) Subject : Re: error in object.h (CLN) ? > > There's only 2 and 4. > > Now CL_WIDE_POINTERS is defined only if long_bitsize is 64, I'm sorry but now I'm not in Italy, so I don't remember where I found this relationship. By the way, I missed during the compiling of intparam.c to define _HAVE_LONGLONG. If I add this define, because LONGLONG is ok on VMS, the intparam.h is quite different. Anyway I had always the problem. So, just to test, I modified manually the long_bitsize definition to 64 (in intparam.h), and all was fine. > > Where did you get that from? In cln/objec.h:70 it's defined only if > cl_pointer_size is 64. And these two are a priori unrelated. Yes... but I remember, but I'm not sure I don't have now the source code, that if cl_pointer_size is related to long_bitsize... I'll try to download the source code on my laptop and I'll check :-) regards, fausto

1 0