August 2010 - GiNaC-list

get_name() doesn't returned a name like "symbolNNN"?
by Warren Weckesser 09 Dec '10

09 Dec '10

Hi, According to the documentation (section 4.5 of the online tutorial), the following code should produce something like z.get_name() = "symbol1" but with ginac 1.5.8, I get an empty string. ----- #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol z; cout << "z.get_name() = \"" << z.get_name() << "\"" << endl; return 0; } ----- In an older version of ginac, this used to work as documented. Is this a bug, or an expected change in behavior? (Or is it just my installation that is broken?) Regards, Warren

3 3

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