- GiNaC-list - ginac.de

Crash Ginsh when trying to solve equation involving integral numerically
by Ernst Moritz Hahn 31 Aug '10

31 Aug '10

Hi, I tried to solve an equation numerically, using Ginsh from the git repository. When entering fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100) into Ginsh, it crashes, see below. I got the same problem with the version shipped with the latest stable Ubuntu Linux. GCC version is "gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3". If you need more information, please tell me. Regards, Moritz emh@mate:~/ginac$ ./ginsh/ginsh ginsh - GiNaC Interactive Shell (ginac V1.5.0) __, _______ Copyright (C) 1999-2010 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. Type ?? for a list of help topics. > fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100); *** glibc detected *** /home/emh/ginac/ginsh/.libs/lt-ginsh: malloc(): memory corruption (fast): 0x091c7cdf *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x7b3591] /lib/tls/i686/cmov/libc.so.6(+0x6e710)[0x7b6710] /lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x5c)[0x7b7f9c] /usr/lib/libstdc++.so.6(_Znwj+0x27)[0x70fc07] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNSt6vectorIN5GiNaC6expairESaIS1_EE7reserveEj+0x62)[0x3d4522] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNK5GiNaC9expairseq12subschildrenERKSt3mapINS_2exES2_NS_10ex_is_lessESaISt4pairIKS2_S2_EEEj+0x145)[0x414745] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNK5GiNaC9expairseq4subsERKSt3mapINS_2exES2_NS_10ex_is_lessESaISt4pairIKS2_S2_EEEj+0x37)[0x417347] /home/emh/ginac/ginsh/.libs/lt-ginsh(_ZNK5GiNaC9containerISt6vectorE12subschildrenERKSt3mapINS_2exES4_NS_10ex_is_lessESaISt4pairIKS4_S4_EEEj+0x65)[0x8062375] /home/emh/ginac/ginsh/.libs/lt-ginsh(_ZNK5GiNaC9containerISt6vectorE4subsERKSt3mapINS_2exES4_NS_10ex_is_lessESaISt4pairIKS4_S4_EEEj+0x2c)[0x80625fc] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNK5GiNaC9expairseq12subschildrenERKSt3mapINS_2exES2_NS_10ex_is_lessESaISt4pairIKS2_S2_EEEj+0x25c)[0x41485c] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNK5GiNaC9expairseq4subsERKSt3mapINS_2exES2_NS_10ex_is_lessESaISt4pairIKS2_S2_EEEj+0x37)[0x417347] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZNK5GiNaC2ex4subsERKS0_j +0x1e0)[0x40eeb0] /home/emh/ginac/ginac/.libs/libginac-1.5.so.0(_ZN5GiNaC6fsolveERKNS_2exERKNS_6symbolERKNS_7numericES8_+0x1bfd)[0x47262d] /home/emh/ginac/ginsh/.libs/lt-ginsh[0x8059103] /home/emh/ginac/ginsh/.libs/lt-ginsh[0x805b52e] /home/emh/ginac/ginsh/.libs/lt-ginsh[0x805d64f] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x75ebd6] /home/emh/ginac/ginsh/.libs/lt-ginsh[0x8052ee1] ======= Memory map: ======== 00110000-00144000 r-xp 00000000 08:01 2359427 /lib/libncurses.so.5.7 00144000-00145000 ---p 00034000 08:01 2359427 /lib/libncurses.so.5.7 00145000-00147000 r--p 00034000 08:01 2359427 /lib/libncurses.so.5.7 00147000-00148000 rw-p 00036000 08:01 2359427 /lib/libncurses.so.5.7 00148000-002ca000 r-xp 00000000 08:01 2930970 /usr/lib/libcln.so.6.0.1 002ca000-002cc000 r--p 00182000 08:01 2930970 /usr/lib/libcln.so.6.0.1 002cc000-002d2000 rw-p 00184000 08:01 2930970 /usr/lib/libcln.so.6.0.1 002d2000-002d4000 rw-p 00000000 00:00 0 002d4000-002f1000 r-xp 00000000 08:01 2359423 /lib/libgcc_s.so.1 002f1000-002f2000 r--p 0001c000 08:01 2359423 /lib/libgcc_s.so.1 002f2000-002f3000 rw-p 0001d000 08:01 2359423 /lib/libgcc_s.so.1 002f3000-002f5000 r-xp 00000000 08:01 2363303 /lib/tls/i686/cmov/libdl-2.11.1.so 002f5000-002f6000 r--p 00001000 08:01 2363303 /lib/tls/i686/cmov/libdl-2.11.1.so 002f6000-002f7000 rw-p 00002000 08:01 2363303 /lib/tls/i686/cmov/libdl-2.11.1.so 00365000-00649000 r-xp 00000000 08:01 1250386 /home/emh/ginac/ginac/.libs/libginac-1.5.so.0.0.0 00649000-0064f000 r--p 002e3000 08:01 1250386 /home/emh/ginac/ginac/.libs/libginac-1.5.so.0.0.0 0064f000-00651000 rw-p 002e9000 08:01 1250386 /home/emh/ginac/ginac/.libs/libginac-1.5.so.0.0.0 00651000-00652000 rw-p 00000000 00:00 0 00652000-0073b000 r-xp 00000000 08:01 2885327 /usr/lib/libstdc ++.so.6.0.13 0073b000-0073c000 ---p 000e9000 08:01 2885327 /usr/lib/libstdc ++.so.6.0.13 0073c000-00740000 r--p 000e9000 08:01 2885327 /usr/lib/libstdc ++.so.6.0.13 00740000-00741000 rw-p 000ed000 08:01 2885327 /usr/lib/libstdc ++.so.6.0.13 00741000-00748000 rw-p 00000000 00:00 0 00748000-0089b000 r-xp 00000000 08:01 2363300 /lib/tls/i686/cmov/libc-2.11.1.so 0089b000-0089c000 ---p 00153000 08:01 2363300 /lib/tls/i686/cmov/libc-2.11.1.so 0089c000-0089e000 r--p 00153000 08:01 2363300 /lib/tls/i686/cmov/libc-2.11.1.so 0089e000-0089f000 rw-p 00155000 08:01 2363300 /lib/tls/i686/cmov/libc-2.11.1.so 0089f000-008a2000 rw-p 00000000 00:00 0 008c5000-00924000 r-xp 00000000 08:01 2915588 /usr/lib/libgmp.so.3.5.2 00924000-00925000 r--p 0005e000 08:01 2915588 /usr/lib/libgmp.so.3.5.2 00925000-00926000 rw-p 0005f000 08:01 2915588 /usr/lib/libgmp.so.3.5.2 009e8000-00a03000 r-xp 00000000 08:01 2359473 /lib/ld-2.11.1.so 00a03000-00a04000 r--p 0001a000 08:01 2359473 /lib/ld-2.11.1.so 00a04000-00a05000 rw-p 0001b000 08:01 2359473 /lib/ld-2.11.1.so 00a1c000-00a40000 r-xp 00000000 08:01 2363304 /lib/tls/i686/cmov/libm-2.11.1.so 00a40000-00a41000 r--p 00023000 08:01 2363304 /lib/tls/i686/cmov/libm-2.11.1.so 00a41000-00a42000 rw-p 00024000 08:01 2363304 /lib/tls/i686/cmov/libm-2.11.1.so 00c1d000-00c1e000 r-xp 00000000 00:00 0 [vdso] 00c66000-00c95000 r-xp 00000000 08:01 2359739 /lib/libreadline.so.6.1 00c95000-00c96000 r--p 0002e000 08:01 2359739 /lib/libreadline.so.6.1 00c96000-00c99000 rw-p 0002f000 08:01 2359739 /lib/libreadline.so.6.1 00c99000-00c9a000 rw-p 00000000 00:00 0 08048000-0806f000 r-xp 00000000 08:01 1250662 /home/emh/ginac/ginsh/.libs/lt-ginsh 0806f000-08070000 r--p 00026000 08:01 1250662 /home/emh/ginac/ginsh/.libs/lt-ginsh 08070000-08071000 rw-p 00027000 08:01 1250662 /home/emh/ginac/ginsh/.libs/lt-ginsh 08071000-08072000 rw-p 00000000 00:00 0 09197000-091d9000 rw-p 00000000 00:00 0 [heap] b7600000-b7621000 rw-p 00000000 00:00 0 b7621000-b7700000 ---p 00000000 00:00 0 b77cb000-b780a000 r--p 00000000 08:01 2889421 /usr/lib/locale/en_US.utf8/LC_CTYPE b780a000-b780e000 rw-p 00000000 00:00 0 b7825000-b782c000 r--s 00000000 08:01 2960058 /usr/lib/gconv/gconv-modules.cache b782c000-b782f000 rw-p 00000000 00:00 0 bff86000-bff9b000 rw-p 00000000 00:00 0 [stack] Aborted

3 9

multithreading
by Kraus Philipp 23 Aug '10

23 Aug '10

Hello, I have declared a GiNaC::parser l_parser; in a class method which is called in a multithread. If I show valgrind report I see: ==1084== Possible data race during write of size 1 at 0x1f06e4 by thread #3 ==1084== at 0x1B30F6: std::string::_Rep::_M_set_length_and_sharable(unsigned long) (in /usr/ lib/libstdc++.6.0.4.dylib) ==1084== by 0x1B39FB: std::string::_M_mutate(unsigned long, unsigned long, unsigned long) (in /usr/lib/libstdc++.6.0.4.dylib) ==1084== by 0x1B3A43: std::string::_M_replace_safe(unsigned long, unsigned long, char const*, unsigned long) (in /usr/lib/libstdc++. 6.0.4.dylib) ==1084== by 0x1B3AE7: std::string::assign(char const*, unsigned long) (in /usr/lib/libstdc++.6.0.4.dylib) ==1084== by 0x115D139: GiNaC::lexer::lexer(std::istream*, std::ostream*, std::ostream*) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) ==1084== by 0x1157CC2: GiNaC::parser::parser(std::map<std::string, GiNaC::ex, std::less<std::string>, std::allocator<std::pair<std::string const, GiNaC::ex> > > const&, bool, std::map<std::pair<std::string, unsigned long>, GiNaC::ex (*) (std::vector<GiNaC::ex, std::allocator<GiNaC::ex> > const&), std::less<std::pair<std::string, unsigned long> >, std::allocator<std::pair<std::pair<std::string, unsigned long> const, GiNaC::ex (*)(std::vector<GiNaC::ex, std::allocator<GiNaC::ex> > const&)> > > const&) (in /Developer/opt/Ginac/1.5.8/lib/ libginac-1.5.0.dylib) When will be ginac thread safe and is there such a thing? Thx Phil

4 9

symtab problem with multithread
by Kraus Philipp 21 Aug '10

21 Aug '10

Hi, I try to use a GiNaC::symtab in a thread object. I copy a const reference to the threaded method and get problems on reading the symbols. If I take a symbol from the table with GiNaC::ex x = m_symbols["mysymbol"], I would run on > 1 thread into errors. Valgrind shows this information: Possible data race during write of size 4 at 0x1ea5c04 by thread #1 ==38631== at 0x8137: std::_Rb_tree<std::string, std::pair<std::string const, GiNaC::ex>, std::_Select1st<std::pair<std::string const, GiNaC::ex> >, std::less<std::string>, std::allocator<std::pair<std::string const, GiNaC::ex> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, GiNaC::ex> >*) (in main) ==38631== by 0x92BF: boost::_bi::storage1<boost::_bi::value<worker<double, 2ul> > >::~storage1() (in main) ==38631== by 0xE0B0: boost::thread* boost::thread_group::create_thread<boost::_bi::bind_t<void, boost::_mfi::mf0<void, worker<double, 2ul> >, boost::_bi::list1<boost::_bi::value<worker<double, 2ul> > > > >(boost::_bi::bind_t<void, boost::_mfi::mf0<void, worker<double, 2ul> >, boost::_bi::list1<boost::_bi::value<mworker<double, 2ul> > > >) (in main) I have copied the table with std::copy( p_syms.begin(), p_syms.end(), std::inserter(m_symbols, m_symbols.begin())); p_syms is the original table and m_symbols should be the copy, but it doesn't work. In my thread object I can use a deep copy of the symbol table, because every thread is independed of the other threads. I'm not sure that the problem is a GiNaC problem, but you can give some tips perhaps. Thanks Phil

2 1

ginsh: valgrind reports 26 bytes lost
by Joerg Arndt 17 Aug '10

17 Aug '10

While we are at it: % valgrind --leak-check=full ginsh ==5463== Memcheck, a memory error detector ==5463== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==5463== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==5463== Command: ginsh ==5463== ginsh - GiNaC Interactive Shell (ginac V1.5.8) __, _______ Copyright (C) 1999-2010 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. Type ?? for a list of help topics. > [pressing ctrl-d to exit] ==5463== ==5463== HEAP SUMMARY: ==5463== in use at exit: 743,496 bytes in 486 blocks ==5463== total heap usage: 3,081 allocs, 2,595 frees, 980,701 bytes allocated ==5463== ==5463== 26 bytes in 1 blocks are definitely lost in loss record 15 of 55 ==5463== at 0x4C26C3A: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5463== by 0x59FEEA2: cln::xmalloc(unsigned long) (cl_malloc.cc:28) ==5463== by 0x5A077DD: cln::cl_make_heap_string(char const*) (cl_st_make1.cc:20) ==5463== by 0x5A05866: cln::cl_prin_globals_init_helper::cl_prin_globals_init_helper() (string.h:83) ==5463== by 0x5B27C05: global constructors keyed to cl_SV_number_aprint.cc (io.h:78) ==5463== by 0x5B27C65: ??? (in /usr/local/lib/libcln.so.6.0.1) ==5463== by 0x59FAF8A: ??? (in /usr/local/lib/libcln.so.6.0.1) ==5463== ==5463== LEAK SUMMARY: ==5463== definitely lost: 26 bytes in 1 blocks ==5463== indirectly lost: 0 bytes in 0 blocks ==5463== possibly lost: 0 bytes in 0 blocks ==5463== still reachable: 743,470 bytes in 485 blocks ==5463== suppressed: 0 bytes in 0 blocks ==5463== Reachable blocks (those to which a pointer was found) are not shown. ==5463== To see them, rerun with: --leak-check=full --show-reachable=yes ==5463== ==5463== For counts of detected and suppressed errors, rerun with: -v ==5463== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

1 0

remove entry from symtab
by Kraus Philipp 16 Aug '10

16 Aug '10

Hi, I'm using GiNaC 1.5.8 and have declared a GiNaC::symtab with symbols. How can I remove a symbole (by string name or GiNaC::symbol expression) from the table? I don't find anything about the symtab in the documentation Thanks Phil

2 2

GiNaC kudos
by Stephen Montgomery-Smith 10 Aug '10

10 Aug '10

Hi Guys, I just wrote some programs that use GiNaC to multiply polynomials whose degrees can get into the 1000's, and whose coefficients are as large as 10^10000. GiNaC performed extraordinarily well, and even went a little faster than Mathematica! I am very impressed! (If you are interested, I am trying to analyze results of Luria-Delbruck experiments using Bayesian statistics.) Stephen

2 3

arithmetic error on concat two expressions
by Kraus Philipp 07 Aug '10

07 Aug '10

Hi, I'm new at GiNaC and I use the lib for create a gradient descent algorithm (symbolic calculating). I have a formula "a*x^3+b*y^4" and I subsitute the formula in the error function "0.5*(t - <formula>)^2". After the substitution GiNaC returns the expression "(0.5)*(a*x^3+b*y^4-t)^2". I use this code: GiNaC::ex m_expression; GiNaC::symtab m_exprtable; try { m_expression = l_parser( "a*x^3+b*y^4" ); m_exprtable = l_parser.get_syms(); } catch (...) {} GiNaC::ex l_full; GiNaC::symtab l_table(m_exprtable); l_table["formula"] = m_expression; GiNaC::parser l_parser(l_table); try { l_full = l_parser( "0.5*(t - formula)^2" ); // (*) } catch (...) {} std::cout << l_full << std::endl; I using the version 1.5.8 (on 1.5.7 I had got a compiler error). Is this the correct way for concating two symbolic expression? Do I have forgot anything? Thanks Phil

4 7

is ginac thread safe for this case?
by Cristobal Navarro 26 Jul '10

26 Jul '10

will ginac be thread safe for this case? 1) threads access diferent expressions which are independant 2) each thread will increase the expression its working in.. for example thread1...expression1 += x+y thread2.... expression2 += 2*x.... and so on. 2) no function evaluation is done never. 3) however, all expressions share the same global symbols ( eg, expressions made of global symbols x and y ). 4) threads access the same common matrix of expressions, but two threads will never access the same cell. i'am testing at the moment, and is working but in the long run i am not sure if problems will arise. any information, welcome. thanks in advance. Cristobal <http://www.youtube.com/neoideo>

5 22

Store matrix, then read it?
by Cristobal Navarro 07 Jul '10

07 Jul '10

Hello, i am experiencing a little trouble when reading my stored matrix. when i write and read the same matrix i stored, it works. but if i only run the program to read the matrix file, i get this error. terminate called after throwing an instance of 'std::runtime_error' what(): unknown matrix dimensions in archive This is a one-file example source code i made for you guys so you can test, its based on the same problem i have on my bigger code. try running it as it is, then comment the "write" method and run it again so it only reads the matrices, youll get the error eventually. but you will never get it if you write and read, its weird. how can this be solved? //CODE #include <fstream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; symbol q("q"),v("v"); void read( string filename, GiNaC::matrix* qvCol, GiNaC::matrix* qvMat ); void write( string filename, GiNaC::matrix qvCol, GiNaC::matrix qvMat ); int main(int argc, char** argv){ GiNaC::matrix qvMat(2,2), qvCol(2,1), rm1, rm2; //mat1 qvCol(0,0) = q*v; qvCol(1,0) = 2*q*v; //mat2 qvMat(0,0) = q*v; qvMat(0,1) = 2*q*v; qvMat(1,0) = 3*q*v; qvMat(1,1) = 4*q*v; cout << endl << "m1: " << endl << qvCol << endl; cout << "m2: " << endl << qvMat << endl << endl; write("example.gin", qvCol, qvMat); read("example.gin", &rm1, &rm2); cout << endl << "rm1: " << endl << rm1 << endl; cout << "rm2: " << endl << rm2 << endl << endl; return 0; } void read( string filename, GiNaC::matrix* qvCol, GiNaC::matrix* qvMat ){ cout << "Main::Read File......."; fstream fr(filename.c_str(),ios::in|ios::binary); if( !fr.is_open() ){ printf("bad file\n"); return; } GiNaC::archive_node canCol, canMat; GiNaC::lst syms(q, v); fr >> canCol; fr >> canMat; qvCol->read_archive(canCol, syms); qvMat->read_archive(canMat, syms); fr.close(); cout << "OK: " << filename << endl; } void write( string filename, GiNaC::matrix qvCol, GiNaC::matrix qvMat ){ cout << "Main::Write File......"; fflush(stdout); //abrir archivo para escritura fstream fw(filename.c_str(),ios::out|ios::binary); GiNaC::archive_node anCol, anMat; qvCol.archive( anCol ); qvMat.archive( anMat ); fw << anCol; fw << anMat; fw.close(); cout << "OK: " << filename << endl; } //END

2 2

GiNaC release 1.5.8
by Jens Vollinga 06 Jul '10

06 Jul '10

Hi everybody, GiNaC 1.5.8 is out and available. The changes are: * Changed default behaviour of conjugate() for user-defined functions to avoid wrong evaluations. A user-defined conjugate_func must now be explicitly registered. * Fixed: Parser now handles abbreviations as advertized in the manual. * Fixed two bugs in the GCD code (one infinite loop, one miscalculation). * Fixed dangerous iterator use. * Fixed a memory leak in excompiler. * Fixed several syntax issues wrt to gcc 4.5 and wrt to compile option -std=cxx0x. * Fixed a wrong URL and a texinfo problem in the manual. * Added degree_vector() utility function. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens

1 0