- GiNaC-devel - ginac.de

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

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

06 Apr '04

Hi, I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on starting my demo application. This didn't happen with GiNaC-1.1.7. After looking to the source code I found a problem with the current implementation: In file uitils.cpp the following constants are defined: _num0_p _num0 _ex0 These are initialized on behalf of constructor library_init() which is called by statement static library_init library_initialize from file ex.h (line 53). The constructor function_options::function_options(std::string const & n, std::string const & tn) in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement symtree = 0; in its implementation (line 82). Symtree is of type ex which is initialized by ex(int) which calls basic & ex::construct_from_int(int i) in file ex.cpp (line 329). The relevant line is case 0: return const_cast<numeric &>(_num0); Reference counting, now, forces usage of operator-> on the _num0 object. Now, here is the problem: It may happen that the construtor of function_options() is called before the call of library_init(). function_options() is called during registration of class container by statement GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). The construction order of static objects in different translation units is undefined in C++. Therefore the problem may or may not show up. With kind regards and a lot of respect Johannes

3 2

CLN on VMS
by Fausto Saporito 05 Apr '04

05 Apr '04

Hello all, as first step to compile GINAC, I need CLN under VMS :-) So i'm trying to compile CLN with DEC C++ compiler. I hope this is the right place to post something related to CLN, otherwise I apologize for this. Let's start... Now, i generated config.h and intparam.h and I'm starting from src/base directory. I hope it's fine. By the way, I have some probs with io.h file, it seems that DEC compiler complaints a lot about it :-) For example, this is an output for cl_as_err.cc (i'm sorry for the output but it's very ugly I know!) Just two notes: 1) I have to remove all std:: occurence before a stream, because the compiler doesn't like them :-) I don't know why 2) It seems the cl_FN_tag is not defined, but I checked in object.h and i think it's all ok. If somebody knows what could be the reason, should be great! $ cxx/include_dir=("../../include","dka0:[porting.dist.include]") cl_as_err.cc void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_gcobject::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 339 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_gcpointer::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 389 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_rcobject::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 439 in file DKA0:[WORK.cln116.include.cln]object.h;2 void* operator new (size_t size, void* ptr) { (void)size; return ptr; } ..............^ %CXX-W-NOCORDEL, function "cln::cl_rcpointer::operator new(size_t, void *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object) at line number 489 in file DKA0:[WORK.cln116.include.cln]object.h;2 : cl_gcobject ((cl_private_thing) cl_combine(cl_FN_tag,0)) {} .....................................................^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 187 in file DKA0:[WORK.cln116.include.cln]number.h;2 CL_DEFINE_INT_CONSTRUCTORS(cl_number) ^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 191 in file DKA0:[WORK.cln116.include.cln]number.h;2 CL_DEFINE_INT_ASSIGNMENT_OPERATORS(cl_number) ^ %CXX-E-UNDECLARED, identifier "cl_FN_tag" is undefined at line number 192 in file DKA0:[WORK.cln116.include.cln]number.h;2 %CXX-I-MESSAGE, 5 errors detected in the compilation of "DKA0:[WORK.cln116.src.base]cl_as_err.cc;3". thanks in advance, Fausto

2 1

error in object.h (CLN) ?
by Fausto Saporito 05 Apr '04

05 Apr '04

Hi all, following my previous posting about cln compiling under VMS (Alpha arch) I found an error (???) in object.h file. The cl_word_alignment for alpha machines is 8, but in this define there's no such value: // Definition of the tags. #if !defined(CL_WIDE_POINTERS) #if (cl_word_alignment == 2) #define cl_FN_tag 1 #define cl_SF_tag 3 // must satisfy the cl_immediate_p predicate! #endif #if (cl_word_alignment == 4) #define cl_FN_tag 1 #define cl_SF_tag 2 #endif #else // CL_WIDE_POINTERS // Single Floats are immediate as well. #define cl_FN_tag 1 #define cl_SF_tag 2 #define cl_FF_tag 3 #endif There's only 2 and 4. Now CL_WIDE_POINTERS is defined only if long_bitsize is 64, I checked in my intparam.h (generated by intparam.c) and long_bitsize is 32. Is it correct for an Alpha machine? Maybe it's correct that 8 is missing because in this case CL_WIDE_POINTERS should be defined and all is fine. Please, someone could check this? thanks a lot, Fausto

2 1

Re: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP
by 程伯群 05 Apr '04

05 Apr '04

Hello,Johannes Brunen! I can't say anything about your trouble. But I have a trouble about ginac-1.1.7. I had tyied to insatll ginac1.1.7 using MinGW(but no MSYS) on windows XP, but I failed. You said you had build ginac1.1.7 successfully on the windows XP, Would you tell me how did you do it? I read this mail:http://www.ginac.de/lists/ginac-list/msg00410.html Did you meet this trouble ever? Thank you very much! sincerely, Boqun Cheng ======= 2004-04-05 11:34:00 You say:====== >Hi, > >I'm not subscribed to this list, but I have detected a problem with the new release of GiNaC, which I would like to report. > >After properly building GiNaC-1.2.0 on windows XP using the MinGW / MSYS platform I got a segmentation fault on >starting my demo application. This didn't happen with GiNaC-1.1.7. > >After looking to the source code I found a problem with the current implementation: > >In file uitils.cpp the following constants are defined: >_num0_p >_num0 >_ex0 > >These are initialized on behalf of constructor library_init() which is called by statement >static library_init library_initialize from file ex.h (line 53). > >The constructor function_options::function_options(std::string const & n, std::string const & tn) >in file function.cpp (line 56) calls function initialize() (line 67 )which has a statement >symtree = 0; in its implementation (line 82). > >Symtree is of type ex which is initialized by ex(int) which calls >basic & ex::construct_from_int(int i) in file ex.cpp (line 329). >The relevant line is case 0: return const_cast<numeric &>(_num0); > >Reference counting, now, forces usage of operator-> on the _num0 object. >Now, here is the problem: It may happen that the construtor of function_options() is called before >the call of library_init(). >function_options() is called during registration of class container by statement >GINAC_DECLARE_REGISTERED_CLASS(container, basic) in file container.h (line 130). > >The construction order of static objects in different translation units is undefined in C++. Therefore >the problem may or may not show up. > >With kind regards and a lot of respect > >Johannes ==== 　　　　　　　　cbq(a)software.ict.ac.cn 　　　　　　　　　　2004-04-05

1 0

calling ginac from Fortran 90
by Fausto Saporito 03 Apr '04

03 Apr '04

Hello all, I'm wondering if it's possible to call GINAC from Fortran 90 programs. Do you have any hints? thanks in advance, Fausto

2 4

series expansion.
by Chris Dams 27 Mar '04

27 Mar '04

Hello everybody, Question: what is the output of ex test=1+power(x,4)*sqrt(1+x*x); cout << test.series(x==0,2) << endl; Answer: Order(1) Question: Why? Answer: Because in the x-involving product order=2, degsum=4, ldegree of the sqrt is 0, the sqrt is expanded up to order -2 and Order(x^2)*Order(x^-2)=Order(1). Question: What is to be done now? Answer: Have a look at the attached patch. Bye, Chris Dams

2 1