From varg at theor.jinr.ru Mon Nov 5 18:29:45 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Mon, 5 Nov 2007 20:29:45 +0300 Subject: [GiNaC-devel] (attempt 2) fix ncmul::expand regression In-Reply-To: References: <47138ACF.mailIJX11N7XG@h654732.serverkompetenz.net> <4713DB76.1030606@ginac.de> <20071016055113.GA13581@theor.jinr.ru> Message-ID: <20071105172945.GA29642@theor.jinr.ru> Hello! On Sun, Oct 21, 2007 at 01:26:45PM +0100, Vladimir V. Kisil wrote: > Actually, the patch introduces problems which are not specific to > clifford.cpp. In the self-check errors start from color.cpp, see the > relevant portion of check/exams.out file below. Could your patch > breaks simplification of indexed object somehow? Yep. That patch is somewhat insane, here is the [more] correct (i.e. `make check' does not report any errors) one: [PATCH] Attempt to fix ncmul performance regression due to dummy indices renaming. Do not rename dummy indices if the object has no indices at all. --- ginac/ncmul.cpp | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/ginac/ncmul.cpp b/ginac/ncmul.cpp index 3712329..34f2c7b 100644 --- a/ginac/ncmul.cpp +++ b/ginac/ncmul.cpp @@ -124,18 +124,19 @@ bool ncmul::info(unsigned inf) const return inherited::info(inf); } -typedef std::vector intvector; +typedef std::vector uintvector; ex ncmul::expand(unsigned options) const { + const bool skip_idx_rename = ! info(info_flags::has_indices); // First, expand the children std::auto_ptr vp = expandchildren(options); const exvector &expanded_seq = vp.get() ? *vp : this->seq; // Now, look for all the factors that are sums and remember their // position and number of terms. - intvector positions_of_adds(expanded_seq.size()); - intvector number_of_add_operands(expanded_seq.size()); + uintvector positions_of_adds(expanded_seq.size()); + uintvector number_of_add_operands(expanded_seq.size()); size_t number_of_adds = 0; size_t number_of_expanded_terms = 1; @@ -167,7 +168,7 @@ ex ncmul::expand(unsigned options) const exvector distrseq; distrseq.reserve(number_of_expanded_terms); - intvector k(number_of_adds); + uintvector k(number_of_adds); /* Rename indices in the static members of the product */ exvector expanded_seq_mod; @@ -176,30 +177,37 @@ ex ncmul::expand(unsigned options) const for (size_t i=0; i setflag(status_flags::dynallocated | (options == 0 ? status_flags::expanded : 0))); // increment k[] - int l = number_of_adds-1; - while ((l>=0) && ((++k[l]) >= number_of_add_operands[l])) { + size_t l = number_of_adds - 1; + while ((++k[l]) >= number_of_add_operands[l]) { k[l] = 0; - l--; + if (l == 0) { + show_must_go_on = false; + break; + } + else + --l; } - if (l<0) - break; } return (new add(distrseq))-> -- 1.5.3.2 > By the way, I failed to apply your patch through the command > > patch -p1 < p.diff Interesting. Both patches work for me (TM), that is, I can apply them to current HEAD (and ginac_1-4) with patch -p1. > What is the correct way to apply it? patch -p1 < that_file.diff Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From kisilv at maths.leeds.ac.uk Mon Nov 5 19:47:24 2007 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Mon, 05 Nov 2007 18:47:24 +0000 Subject: [GiNaC-devel] (attempt 2) fix ncmul::expand regression In-Reply-To: <20071105172945.GA29642@theor.jinr.ru> References: <47138ACF.mailIJX11N7XG@h654732.serverkompetenz.net> <4713DB76.1030606@ginac.de> <20071016055113.GA13581@theor.jinr.ru> <20071105172945.GA29642@theor.jinr.ru> Message-ID: <8401.1194288444@localhost> Hello, Alexei, >>>>> "AS" == Alexei Sheplyakov writes: AS> Yep. That patch is somewhat insane, here is the [more] correct AS> (i.e. `make check' does not report any errors) one: I tried the patch on my two large programs with Clifford numbers: no problems are observed. I did not collect the official benchmarks but some speed-up also presents. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ From varg at theor.jinr.ru Tue Nov 6 16:52:47 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Tue, 6 Nov 2007 18:52:47 +0300 Subject: [GiNaC-devel] [PATCH] fix broken perprocessor instruction, so GiNaC compiles when ! HAVE_LIBDL. Message-ID: <20071106155247.GA22686@theor.jinr.ru> Hi! I've tried to build GiNaC 1.4 on my ReactOS box, it failed due to broken preprocessor instruction in excomplier.cpp. The patch below fixes it. --- ginac/excompiler.cpp | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/ginac/excompiler.cpp b/ginac/excompiler.cpp index fe96123..4cf2841 100644 --- a/ginac/excompiler.cpp +++ b/ginac/excompiler.cpp @@ -32,7 +32,9 @@ #include #include +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #ifdef HAVE_LIBDL #include @@ -302,7 +304,7 @@ void unlink_ex(const std::string filename) global_excompiler.unlink(filename); } -#elif // def HAVE_LIBDL +#else // def HAVE_LIBDL /* * In case no working libdl has been found by configure, the following function -- 1.5.3.2 -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Sat Nov 17 17:35:23 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Sat, 17 Nov 2007 19:35:23 +0300 Subject: [GiNaC-devel] [PATCH] Fix memory leaks in mul::eval() and power::eval() (GiNaC 1.3) Message-ID: <20071117163523.GA12482@theor.jinr.ru> The bug was introduced by the patch commit f418c6ee4d558c852e1fb95533af07a3ae43f409 Author: Alexei Sheplyakov Date: Wed Jul 11 14:34:42 2007 +0400 (it was commited into the official branch as commit a602d34c225dceb3e53742a7b3e19a4b5e280485 Author: Jens Vollinga Date: Wed Jul 11 21:07:40 2007 +0000) While at it, delete bogus try -- catch block in the ex::series(), since it papers over some serious issues (like this one) and does not seem to do anything useful. Thanks to valgrind (http://valgrind.kde.org) developers for a wonderful piece of software. Debugging this problem would take way too long without it. --- check/mul_eval_memleak.cpp | 119 ++++++++++++++++++++++++++++++++++++++++++++ ginac/mul.cpp | 4 +- ginac/power.cpp | 4 +- ginac/pseries.cpp | 6 +-- 4 files changed, 124 insertions(+), 9 deletions(-) create mode 100644 check/mul_eval_memleak.cpp diff --git a/check/mul_eval_memleak.cpp b/check/mul_eval_memleak.cpp new file mode 100644 index 0000000..78e9312 --- /dev/null +++ b/check/mul_eval_memleak.cpp @@ -0,0 +1,119 @@ +/** + * @file mul_eval_memleak.cpp Test for memory leak in {mul,power}::eval + * + * The bug was introduced by + * + * commit f418c6ee4d558c852e1fb95533af07a3ae43f409 + * Author: Alexei Sheplyakov + * Date: Wed Jul 11 14:34:42 2007 +0400 + * (it was commited into the official branch as + * commit a602d34c225dceb3e53742a7b3e19a4b5e280485 + * Author: Jens Vollinga + * Date: Wed Jul 11 21:07:40 2007 +0000) + */ + +/* + * GiNaC Copyright (C) 1999-2007 Johannes Gutenberg University Mainz, Germany + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +using namespace std; +using namespace GiNaC; + +const unsigned check_mul_eval_memleak(const unsigned N) +{ + // Expanding this expression into a Laurent series triggers the bug. + static const string e_str("\ +1/605927415293858601*tgamma(3-eps)^(-1)*tgamma(2-eps)*(5013234896802\ +*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale\ +^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+(846400+2539001*eps\ +)*(2539001*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log\ +(920*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+286523497\ +2800*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-\ +1))^(-2*eps)*tgamma(1+eps)^2)+6061411748045832000*(-1+eps)^(-1)*eps^\ +(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+e\ +ps)^2+716056132401*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(92\ +0*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F))+71656139360\ +0/716056132401*tgamma(1-eps)*tgamma(2*eps)^(-1)*tgamma(eps)^2*tgamma\ +(3-eps)^(-1)*(920*scale^(-1))^(-4*eps)*tgamma(-1+2*eps)-2/6059274152\ +93858601*tgamma(3-eps)^(-1)*(2149010446400*(-1+2*eps)*((-2539001/2)*\ +eps^(-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*log(1301*sc\ +ale^(-1)))*eps^(-1)+F)+2425134880977920000*(-1+eps)^(-1)*eps^(-2)*(9\ +20*scale^(-1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+eps)^2-7\ +16056132401*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale\ +^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+1692601*(-1+2*eps)*\ +(2539001*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(9\ +20*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+28652349728\ +00*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-1)\ +)^(-2*eps)*tgamma(1+eps)^2))*tgamma(2-eps)+(1/716056132401*I)*tgamma\ +(-1+eps)*mb^2*(mb*scale^(-1))^(-2*eps)*((716392960000*I)*mb^(-2)*(92\ +0*scale^(-1))^(-2*eps)*tgamma(-2+eps)-(2864898145201*I)*mb^(-2)*(130\ +1*scale^(-1))^(-2*eps)*tgamma(-2+eps)-(716224526400*I)*tgamma(-1+eps\ +)*mb^(-2)*(920*scale^(-1))^(-2*eps))-3385202/605927415293858601*tgam\ +ma(3-eps)^(-1)*tgamma(2-eps)*(2539001*(-1+2*eps)*((-2539001/2)*eps^(\ +-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*log(1301*scale^(\ +-1)))*eps^(-1)+F)+2865234972800*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-\ +1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+eps)^2+846201*((-25\ +39001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*lo\ +g(1301*scale^(-1)))*eps^(-1)+F))\ +"); + const symbol eps("eps"), scale("scale"), mb("mb"), F("F"); + const lst syms(eps, scale, mb, F); + const ex e0(e_str, syms); + + unsigned i = 0; + unsigned n_failures = 0; + + ex e; + try { + for (; i < N; i++) + e = e0.series(eps, 1).subs(Euler==0).expand(); + } catch (std::bad_alloc) { + return i; + } + return 0; +} + +#include +#include +#include +#include + +static void set_VM_limit(const unsigned long MB) { + const unsigned mem_lim_kb = MB*1024*1024; + struct rlimit lim; + lim.rlim_cur = mem_lim_kb; + lim.rlim_max = mem_lim_kb; + setrlimit(RLIMIT_AS, &lim); +} + +int main(int argc, char** argv) { + static const unsigned max_mem = 32; // megabytes + // otherwise one need wait for a long[er] time. + set_VM_limit(max_mem); + static const unsigned n_of_tests = 10000; + const unsigned n_loops = check_mul_eval_memleak(n_of_tests); + if (n_loops) { + cerr << "memory exhausted after " << n_loops << " loops" << endl; + return 1; + } + return 0; +} + diff --git a/ginac/mul.cpp b/ginac/mul.cpp index 99d811f..ab1a042 100644 --- a/ginac/mul.cpp +++ b/ginac/mul.cpp @@ -461,8 +461,8 @@ ex mul::eval(int level) const // XXX: What is the best way to check if the polynomial is a primitive? numeric c = i->rest.integer_content(); - const numeric& lead_coeff = - ex_to(ex_to(i->rest).seq.begin()->coeff).div_dyn(c); + const numeric lead_coeff = + ex_to(ex_to(i->rest).seq.begin()->coeff).div(c); const bool canonicalizable = lead_coeff.is_integer(); // XXX: The main variable is chosen in a random way, so this code diff --git a/ginac/power.cpp b/ginac/power.cpp index e839220..099f935 100644 --- a/ginac/power.cpp +++ b/ginac/power.cpp @@ -491,8 +491,8 @@ ex power::eval(int level) const // (2*x + 6*y)^(-4) -> 1/16*(x + 3*y)^(-4) if (num_exponent->is_integer() && is_exactly_a(ebasis)) { numeric icont = ebasis.integer_content(); - const numeric& lead_coeff = - ex_to(ex_to(ebasis).seq.begin()->coeff).div_dyn(icont); + const numeric lead_coeff = + ex_to(ex_to(ebasis).seq.begin()->coeff).div(icont); const bool canonicalizable = lead_coeff.is_integer(); const bool unit_normal = lead_coeff.is_pos_integer(); diff --git a/ginac/pseries.cpp b/ginac/pseries.cpp index 2b948a7..6ff1d96 100644 --- a/ginac/pseries.cpp +++ b/ginac/pseries.cpp @@ -1215,11 +1215,7 @@ ex ex::series(const ex & r, int order, unsigned options) const else throw (std::logic_error("ex::series(): expansion point has unknown type")); - try { - e = bp->series(rel_, order, options); - } catch (std::exception &x) { - throw (std::logic_error(std::string("unable to compute series (") + x.what() + ")")); - } + e = bp->series(rel_, order, options); return e; } -- 1.5.3.2 -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Sat Nov 17 17:36:10 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Sat, 17 Nov 2007 19:36:10 +0300 Subject: [GiNaC-devel] [PATCH] Fix memory leaks in mul::eval() and power::eval() (GiNaC 1.4, HEAD) Message-ID: <20071117163610.GA12675@theor.jinr.ru> The bug was introduced by the patch commit f418c6ee4d558c852e1fb95533af07a3ae43f409 Author: Alexei Sheplyakov Date: Wed Jul 11 14:34:42 2007 +0400 (it was commited into the official branch as commit a602d34c225dceb3e53742a7b3e19a4b5e280485 Author: Jens Vollinga Date: Wed Jul 11 21:07:40 2007 +0000) While at it, delete bogus try -- catch block in the ex::series(), since it papers over some serious issues (like this one) and does not seem to do anything useful. Thanks to valgrind (http://valgrind.kde.org) developers for a wonderful piece of software. Debugging this problem would take way too long without it. --- check/mul_eval_memleak.cpp | 119 ++++++++++++++++++++++++++++++++++++++++++++ ginac/mul.cpp | 4 +- ginac/power.cpp | 4 +- ginac/pseries.cpp | 6 +-- 4 files changed, 124 insertions(+), 9 deletions(-) create mode 100644 check/mul_eval_memleak.cpp diff --git a/check/mul_eval_memleak.cpp b/check/mul_eval_memleak.cpp new file mode 100644 index 0000000..78e9312 --- /dev/null +++ b/check/mul_eval_memleak.cpp @@ -0,0 +1,119 @@ +/** + * @file mul_eval_memleak.cpp Test for memory leak in {mul,power}::eval + * + * The bug was introduced by + * + * commit f418c6ee4d558c852e1fb95533af07a3ae43f409 + * Author: Alexei Sheplyakov + * Date: Wed Jul 11 14:34:42 2007 +0400 + * (it was commited into the official branch as + * commit a602d34c225dceb3e53742a7b3e19a4b5e280485 + * Author: Jens Vollinga + * Date: Wed Jul 11 21:07:40 2007 +0000) + */ + +/* + * GiNaC Copyright (C) 1999-2007 Johannes Gutenberg University Mainz, Germany + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +using namespace std; +using namespace GiNaC; + +const unsigned check_mul_eval_memleak(const unsigned N) +{ + // Expanding this expression into a Laurent series triggers the bug. + static const string e_str("\ +1/605927415293858601*tgamma(3-eps)^(-1)*tgamma(2-eps)*(5013234896802\ +*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale\ +^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+(846400+2539001*eps\ +)*(2539001*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log\ +(920*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+286523497\ +2800*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-\ +1))^(-2*eps)*tgamma(1+eps)^2)+6061411748045832000*(-1+eps)^(-1)*eps^\ +(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+e\ +ps)^2+716056132401*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(92\ +0*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F))+71656139360\ +0/716056132401*tgamma(1-eps)*tgamma(2*eps)^(-1)*tgamma(eps)^2*tgamma\ +(3-eps)^(-1)*(920*scale^(-1))^(-4*eps)*tgamma(-1+2*eps)-2/6059274152\ +93858601*tgamma(3-eps)^(-1)*(2149010446400*(-1+2*eps)*((-2539001/2)*\ +eps^(-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*log(1301*sc\ +ale^(-1)))*eps^(-1)+F)+2425134880977920000*(-1+eps)^(-1)*eps^(-2)*(9\ +20*scale^(-1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+eps)^2-7\ +16056132401*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale\ +^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+1692601*(-1+2*eps)*\ +(2539001*(-1+2*eps)*((-2539001/2)*eps^(-2)+(-7617003/2+1692800*log(9\ +20*scale^(-1))+3385202*log(1301*scale^(-1)))*eps^(-1)+F)+28652349728\ +00*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-1))^(-2*eps)*(1301*scale^(-1)\ +)^(-2*eps)*tgamma(1+eps)^2))*tgamma(2-eps)+(1/716056132401*I)*tgamma\ +(-1+eps)*mb^2*(mb*scale^(-1))^(-2*eps)*((716392960000*I)*mb^(-2)*(92\ +0*scale^(-1))^(-2*eps)*tgamma(-2+eps)-(2864898145201*I)*mb^(-2)*(130\ +1*scale^(-1))^(-2*eps)*tgamma(-2+eps)-(716224526400*I)*tgamma(-1+eps\ +)*mb^(-2)*(920*scale^(-1))^(-2*eps))-3385202/605927415293858601*tgam\ +ma(3-eps)^(-1)*tgamma(2-eps)*(2539001*(-1+2*eps)*((-2539001/2)*eps^(\ +-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*log(1301*scale^(\ +-1)))*eps^(-1)+F)+2865234972800*(-1+eps)^(-1)*eps^(-2)*(920*scale^(-\ +1))^(-2*eps)*(1301*scale^(-1))^(-2*eps)*tgamma(1+eps)^2+846201*((-25\ +39001/2)*eps^(-2)+(-7617003/2+1692800*log(920*scale^(-1))+3385202*lo\ +g(1301*scale^(-1)))*eps^(-1)+F))\ +"); + const symbol eps("eps"), scale("scale"), mb("mb"), F("F"); + const lst syms(eps, scale, mb, F); + const ex e0(e_str, syms); + + unsigned i = 0; + unsigned n_failures = 0; + + ex e; + try { + for (; i < N; i++) + e = e0.series(eps, 1).subs(Euler==0).expand(); + } catch (std::bad_alloc) { + return i; + } + return 0; +} + +#include +#include +#include +#include + +static void set_VM_limit(const unsigned long MB) { + const unsigned mem_lim_kb = MB*1024*1024; + struct rlimit lim; + lim.rlim_cur = mem_lim_kb; + lim.rlim_max = mem_lim_kb; + setrlimit(RLIMIT_AS, &lim); +} + +int main(int argc, char** argv) { + static const unsigned max_mem = 32; // megabytes + // otherwise one need wait for a long[er] time. + set_VM_limit(max_mem); + static const unsigned n_of_tests = 10000; + const unsigned n_loops = check_mul_eval_memleak(n_of_tests); + if (n_loops) { + cerr << "memory exhausted after " << n_loops << " loops" << endl; + return 1; + } + return 0; +} + diff --git a/ginac/mul.cpp b/ginac/mul.cpp index 4e95a63..9e1ba48 100644 --- a/ginac/mul.cpp +++ b/ginac/mul.cpp @@ -469,8 +469,8 @@ ex mul::eval(int level) const // XXX: What is the best way to check if the polynomial is a primitive? numeric c = i->rest.integer_content(); - const numeric& lead_coeff = - ex_to(ex_to(i->rest).seq.begin()->coeff).div_dyn(c); + const numeric lead_coeff = + ex_to(ex_to(i->rest).seq.begin()->coeff).div(c); const bool canonicalizable = lead_coeff.is_integer(); // XXX: The main variable is chosen in a random way, so this code diff --git a/ginac/power.cpp b/ginac/power.cpp index 7d909e8..cbf196f 100644 --- a/ginac/power.cpp +++ b/ginac/power.cpp @@ -505,8 +505,8 @@ ex power::eval(int level) const // (2*x + 6*y)^(-4) -> 1/16*(x + 3*y)^(-4) if (num_exponent->is_integer() && is_exactly_a(ebasis)) { numeric icont = ebasis.integer_content(); - const numeric& lead_coeff = - ex_to(ex_to(ebasis).seq.begin()->coeff).div_dyn(icont); + const numeric lead_coeff = + ex_to(ex_to(ebasis).seq.begin()->coeff).div(icont); const bool canonicalizable = lead_coeff.is_integer(); const bool unit_normal = lead_coeff.is_pos_integer(); diff --git a/ginac/pseries.cpp b/ginac/pseries.cpp index 0da6ae8..f4571ed 100644 --- a/ginac/pseries.cpp +++ b/ginac/pseries.cpp @@ -1280,11 +1280,7 @@ ex ex::series(const ex & r, int order, unsigned options) const else throw (std::logic_error("ex::series(): expansion point has unknown type")); - try { - e = bp->series(rel_, order, options); - } catch (std::exception &x) { - throw (std::logic_error(std::string("unable to compute series (") + x.what() + ")")); - } + e = bp->series(rel_, order, options); return e; } -- 1.5.3.2 -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Sun Nov 18 18:12:57 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Sun, 18 Nov 2007 20:12:57 +0300 Subject: [GiNaC-devel] [PATCH] Constructing expression from a string does not leak memory any more. Message-ID: <20071118171257.GA25808@theor.jinr.ru> Thanks to valgrind for spotting this. --- check/parser_memleak.cpp | 36 ++++++++++++++++++++++++++++++++++++ ginac/input_lexer.ll | 4 +++- 2 files changed, 39 insertions(+), 1 deletions(-) create mode 100644 check/parser_memleak.cpp diff --git a/check/parser_memleak.cpp b/check/parser_memleak.cpp new file mode 100644 index 0000000..f347ce9 --- /dev/null +++ b/check/parser_memleak.cpp @@ -0,0 +1,36 @@ +/** + * This small program exhibits the memory leak in the ginac_yylex(). + * Run it as + * + * valgrind --leak-check=yes ./parser_memleak + * + * or simply + * + * ulimit -v `expr 64 \* 1024` ./parser_memleak + */ +#include +#include +#include +using namespace std; +using namespace GiNaC; + +int main(int argc, char** argv) { + const symbol x("x"), y("y"); + const lst syms(x, y); + // parser-generated symbol => memory leak. + static const char* str[] = { "x^2+2*x*y + cos(x)", "Li2(x/y) + log(y/x)" }; + + // depends on the amount of the available VM, compiler options, etc. + const unsigned N_max = 500000; + unsigned N=0; + ex e; + try { + for (; N < N_max; N++) { + e = ex(str[N & 1], syms); + } + } catch (std::bad_alloc) { + cerr << "N = " << N << endl; + return 1; + } + return 0; +} diff --git a/ginac/input_lexer.ll b/ginac/input_lexer.ll index f931394..bc568ce 100644 --- a/ginac/input_lexer.ll +++ b/ginac/input_lexer.ll @@ -119,7 +119,9 @@ Digits ginac_yylval = (long)Digits; return T_DIGITS; {A}{AN}* { sym_tab::const_iterator i = syms.find(yytext); if (i == syms.end()) { - syms[yytext] = sym_def(ginac_yylval = *(new symbol(yytext)), false); + symbol tmp(yytext); + ginac_yylval = tmp; + syms[yytext] = sym_def(tmp, false); } else ginac_yylval = (*i).second.sym; return T_SYMBOL; -- 1.5.3.2 Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Mon Nov 19 11:19:30 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Mon, 19 Nov 2007 13:19:30 +0300 Subject: [GiNaC-devel] bugfix-only release? Message-ID: <20071119101930.GA16798@theor.jinr.ru> Hi! Since two serious bugs have been fixed, it would be nice to make a bugfix-only release (1.3.9 and 1.4.1). If anyone has objections, or some patches, or problems/issues to be resolved first, please let me know. Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From vollinga at physik.uni-wuppertal.de Mon Nov 19 23:01:49 2007 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Mon, 19 Nov 2007 23:01:49 +0100 Subject: [GiNaC-devel] bugfix-only release? In-Reply-To: <20071119101930.GA16798@theor.jinr.ru> References: <20071119101930.GA16798@theor.jinr.ru> Message-ID: <474207CD.7010300@physik.uni-wuppertal.de> Hi, Alexei Sheplyakov schrieb: > Since two serious bugs have been fixed, it would be nice to make a bugfix-only > release (1.3.9 and 1.4.1). If anyone has objections, or some patches, > or problems/issues to be resolved first, please let me know. good idea! I will have a look at all the pending patches tomorrow and then probably tomorrow evening I will roll the releases. Regards, Jens From varg at theor.jinr.ru Tue Nov 20 06:39:47 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Tue, 20 Nov 2007 08:39:47 +0300 Subject: [GiNaC-devel] some pending patches (was: bugfix-only release?) In-Reply-To: <474207CD.7010300@physik.uni-wuppertal.de> References: <20071119101930.GA16798@theor.jinr.ru> <474207CD.7010300@physik.uni-wuppertal.de> Message-ID: <20071120053947.GA4487@theor.jinr.ru> Hello! > I will have a look at all the pending patches tomorrow and then probably > tomorrow evening I will roll the releases. I have some small patches too. I've already posted this one, but it got lost for some reason: [PATCH] build: really fix macro checking for version of libreadline. This helps to detect (and reject) non-GNU versions of libreadline, so that build on Mac OS X won't fail. --- acinclude.m4 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 64f4ec3..9fe93f6 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -26,7 +26,7 @@ int main() return 0; }], [ dnl Some non-GNU readline implementations have non-numeric rl_library_version -ginac_cv_rlversion=`sed -e 's/[^0-9.]//g' 'conftest.out'`], [ ginac_cv_rlversion='unknown'], [ ginac_cv_rlversion='4.2'])]) +ginac_cv_rlversion=`sed -e 's/[[^0-9.]]//g' 'conftest.out'`], [ ginac_cv_rlversion='unknown'], [ ginac_cv_rlversion='4.2'])]) if test -z "$ginac_cv_rlversion"; then GINAC_WARNING([Unsupported version of libreadline.]) ginac_cv_rlversion='unknown' -- 1.5.3.2 Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Tue Nov 20 13:43:25 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Tue, 20 Nov 2007 15:43:25 +0300 Subject: [GiNaC-devel] more pending patches (GiNaC 1.3) In-Reply-To: <474207CD.7010300@physik.uni-wuppertal.de> References: <20071119101930.GA16798@theor.jinr.ru> <474207CD.7010300@physik.uni-wuppertal.de> Message-ID: <20071120124325.GA12145@theor.jinr.ru> [PATCH] INSTALL: do not mention nonexisting autogen.sh (GiNaC 1.3) That file was removed a long time ago, so... --- INSTALL | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/INSTALL b/INSTALL index 2c60d2d..1fda652 100644 --- a/INSTALL +++ b/INSTALL @@ -60,9 +60,8 @@ library works correctly you can use $ make check -The "configure" script (and "autogen.sh", which invokes "configure") can be -given a number of options to enable and disable various features. For a -complete list, type: +The "configure" script can be given a number of options to enable and +disable various features. For a complete list, type: $ ./configure --help -- 1.5.3.2 1.4 (and HEAD) branches do not need this patch. Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From vollinga at physik.uni-wuppertal.de Tue Nov 20 23:47:20 2007 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Tue, 20 Nov 2007 23:47:20 +0100 Subject: [GiNaC-devel] Upcoming release Message-ID: <474363F8.1080402@physik.uni-wuppertal.de> Hi, I think I have done all patches now. For tomorrow evening I plan to do the releases 1.3.9 and 1.4.1. Regards, Jens From varg at theor.jinr.ru Wed Nov 21 07:33:35 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Wed, 21 Nov 2007 09:33:35 +0300 Subject: [GiNaC-devel] Re: [GiNaC-cvs] check parser_memleak.cpp In-Reply-To: <47435D86.mailI4B11ITZF@h654732.serverkompetenz.net> References: <47435D86.mailI4B11ITZF@h654732.serverkompetenz.net> Message-ID: <20071121063335.GA15731@theor.jinr.ru> Hi! On Tue, Nov 20, 2007 at 11:19:50PM +0100, CVS Service wrote: > Update of /home/cvs/GiNaC/check by vollinga > > Added Files: > parser_memleak.cpp > Log Message: > Added small program that exhibits the memory leak in the ginac_yylex() [Sheplyakov]. The patch got slightly corrupted ("x2" is wrong, it should be "x^2", as here: http://www.ginac.de/pipermail/ginac-devel/2007-November/001264.html). Please apply this fix diff --git a/check/parser_memleak.cpp b/check/parser_memleak.cpp index ebc6ed9..f347ce9 100644 --- a/check/parser_memleak.cpp +++ b/check/parser_memleak.cpp @@ -18,7 +18,7 @@ int main(int argc, char** argv) { const symbol x("x"), y("y"); const lst syms(x, y); // parser-generated symbol => memory leak. - static const char* str[] = { "x2+2*x*y + cos(x)", "Li2(x/y) + log(y/x)" }; + static const char* str[] = { "x^2+2*x*y + cos(x)", "Li2(x/y) + log(y/x)" }; // depends on the amount of the available VM, compiler options, etc. const unsigned N_max = 500000; Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From varg at theor.jinr.ru Wed Nov 21 16:59:23 2007 From: varg at theor.jinr.ru (Alexei Sheplyakov) Date: Wed, 21 Nov 2007 18:59:23 +0300 Subject: [GiNaC-devel] migrating to git? In-Reply-To: <474349B4.4000303@ginac.de> References: <20071119101930.GA16798@theor.jinr.ru> <4741DD73.6040503@ginac.de> <20071120101532.GB4487@theor.jinr.ru> <474349B4.4000303@ginac.de> Message-ID: <20071121155923.GA16511@theor.jinr.ru> Dear GiNaC developers, On Tue, Nov 20, 2007 at 09:55:16PM +0100, Richard B. Kreckel wrote: > Anyway, the discussion how to proceed regarding the SCM should be > continued on ginac-devel. OK. > Seriously, I do not think anyone is too fixed about CVS. The reason it > was chosen was because at that time there was no other free SCM. So, I propose to migrate GiNaC repository to git. What do you think, folks? > Migrating to SVN ASAP would be the natural thing to do but I'm sure this > would not excite you. SVN is not *that* bad, but still it is inconvenient (centralized, branching/merging is unnecessary difficult, no offline mode, etc). > Even with git, I think we should have an official reference repository > from which we make releases simply because this way users always know > where to get prereleases from. Sure. > I guess there's no way to convert the CVS history to git, is there? There is git-cvsimport utility. I use it to sync my git repository [1] with CVS. It happens to work surprisingly well, although there was a minor problem during the initial import [2]. So, we could either clone my repository (excluding -vargs branches), or do the conversion once again. [1] http://theor.jinr.ru/~varg/git/ginac Note: the repository is not browseable, use git to clone it. [2] Some *very* old files (auto* tools helpers) in the CVS are corrupted. This problem never get noticed (I guess nobody ever tried to checkout such an old version). I've edited the history a little bit to pretend those file never existed in the (CVS) repository. I don't think this is a problem, since such files should not be included into the repository in first place. Anyway, they were deleted 6 years ago, so who cares? Best regards, Alexei -- All science is either physics or stamp collecting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From vollinga at physik.uni-wuppertal.de Wed Nov 21 23:06:35 2007 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 21 Nov 2007 23:06:35 +0100 Subject: [GiNaC-devel] GiNaC releases 1.3.9 and 1.4.1 Message-ID: <4744ABEB.3050801@physik.uni-wuppertal.de> Hello everybody, GiNaC 1.4.1 is out and available. The changes are: * Fixed memory leak in ginac_yylex(). * Fixed memory leaks in mul::eval() and power::eval(). * Fixed macro checking for version of libreadline (Mac OS X). * Fixed broken preprocessor instruction in excompiler.cpp. * Fixed broken module loading in excompiler.cpp. * info(info_flags::has_indices) now works for sums and products. * Improved mul::expand(). * Improved CLN output. As always, this release can be downloaded from http://www.ginac.de/Download.html We also made a backporting bug-fix release for the GiNaC 1.3.x series, which contains the following changes: * Fixed memory leak in ginac_yylex(). * Fixed memory leaks in mul::eval() and power::eval(). * Fixed macro checking for version of libreadline (Mac OS X). * info(info_flags::has_indices) now works for sums and products. * Improved CLN output. This package can be downloaded from the ftp server: ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Best wishes, Jens From vollinga at physik.uni-wuppertal.de Wed Nov 21 23:24:00 2007 From: vollinga at physik.uni-wuppertal.de (Jens Vollinga) Date: Wed, 21 Nov 2007 23:24:00 +0100 Subject: [GiNaC-devel] migrating to git? In-Reply-To: <20071121155923.GA16511@theor.jinr.ru> References: <20071119101930.GA16798@theor.jinr.ru> <4741DD73.6040503@ginac.de> <20071120101532.GB4487@theor.jinr.ru> <474349B4.4000303@ginac.de> <20071121155923.GA16511@theor.jinr.ru> Message-ID: <4744B000.4020506@physik.uni-wuppertal.de> Hi, Alexei Sheplyakov schrieb: > So, I propose to migrate GiNaC repository to git. What do you think, > folks? > SVN is not *that* bad, but still it is inconvenient (centralized, > branching/merging is unnecessary difficult, no offline mode, etc). The fact that CVS or SVN is centralized is not a bad thing for me. But the easy branching/merging with git is something I really like! So, if it just happened that from tomorrow on the CVS repository had somehow transformed into a git repository I would count that as an improvement. I am not sure how much non-developers actually use the CVS repository and whether a switch to git would degrade the popularity of that download channel. But somebody would have to make the changes on www.ginac.de and that will not be me. So I don't press for a change and could live with CVS for next years to come. Regards, Jens From kreckel at ginac.de Wed Nov 21 23:53:10 2007 From: kreckel at ginac.de (Richard B. Kreckel) Date: Wed, 21 Nov 2007 23:53:10 +0100 Subject: [GiNaC-devel] Alexei is now an official GiNaC maintainer (was: migrating to git?) In-Reply-To: <20071121155923.GA16511@theor.jinr.ru> References: <20071119101930.GA16798@theor.jinr.ru> <4741DD73.6040503@ginac.de> <20071120101532.GB4487@theor.jinr.ru> <474349B4.4000303@ginac.de> <20071121155923.GA16511@theor.jinr.ru> Message-ID: <4744B6D6.7010107@ginac.de> Dear all, Alexei Sheplyakov wrote: > So, I propose to migrate GiNaC repository to git. What do you think, > folks? First, I think this is a good opportunity to summarize some private exchange that occurred during the last few days between Jens, Alexei and myself (and Christian was consulted, too): Starting now, Alexei Sheplyakov will become one of the maintainers and obtain direct write access to, well, whatever we're going to agree on. Cheers -richy. -- Richard B. Kreckel