[GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-247-gcc94094

[Jens Vollinga]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, ginac_1-5 has been updated
       via  cc94094751459129e1392a93dfa0264adac789a5 (commit)
       via  d71be995fcb751b52145eb0e50467d15fea541cb (commit)
       via  5d6d2c3ff6afd13933203f984a818dbfc76db3a1 (commit)
       via  87ed87c395d6121fe468efc68ee2cd33a7e91200 (commit)
      from  37506ee54aa46203736d657c6e8a64e695303b64 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit cc94094751459129e1392a93dfa0264adac789a5
Author: Alexei Sheplyakov <alexei.sheplyakov at gmail.com>
Date:   Sun Aug 22 23:09:18 2010 +0300

    power::eval(): fix several memory leaks
    
    While working on fsolve bug I've noticed the following in valgrind log:
    
    ==17455== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19
    ==17455==    at 0x4C249C7: operator new(unsigned long) (vg_replace_malloc.c:220)
    ==17455==    by 0x516CA70: GiNaC::power::eval(int) const (power.cpp:540)
    ==17455==    by 0x4FC1E39: GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:310)
    ==17455==    by 0x406FBF: main (ex.h:255)
    
    Heap allocated objects definitely need the status_flags::dyncallocated flag.
    (cherry picked from commit 5f896fa7f59bbce727e4bba23df9c4bbdbb55c29)

commit d71be995fcb751b52145eb0e50467d15fea541cb
Author: Alexei Sheplyakov <alexei.sheplyakov at gmail.com>
Date:   Sat Aug 21 19:13:29 2010 +0300

    fsolve: avoid useless numerical evaluation of the function
    
    Don't compute f(x) if new x is outside of the interval. We don't need that
    value anyway, and the function might be difficult to compute numerically or
    even ill defined outside the interval.
    
    As a result fsolve is able to find root(s) of some weird functions.
    For example
    
    fsolve((1/(sqrt(2*Pi)))*integral(t, 0, x, exp(-1/2*t^2)) == 0.5, x, 0, 100)
    
    actually works now.
    (cherry picked from commit beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032)

commit 5d6d2c3ff6afd13933203f984a818dbfc76db3a1
Author: Alexei Sheplyakov <alexei.sheplyakov at gmail.com>
Date:   Thu Aug 19 11:10:25 2010 +0300

    integral::evalf(): don't attempt to ignore problems.
    
    Don't ignore exceptions thrown by numerical integration routine.
    In general, the code like this
    
    try {
    	// blah-blah
    } catch (std::exception& err) { }
    
    is just plain evil. Case in the point:
    
    fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100)
    (cherry picked from commit 515171f0bcd42099c266713c3d605cd92cedd2e2)

commit 87ed87c395d6121fe468efc68ee2cd33a7e91200
Author: Alexei Sheplyakov <alexei.sheplyakov at gmail.com>
Date:   Thu Aug 19 00:07:13 2010 +0300

    fsolve: check if evalf() return value is actually a number.
    
    Fixes the segfault triggered by
    
    fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100)
    
    In general, ex_to is unsafe, and should be used only after proper checks.
    evalf() may return non-numeric expression for various reasons (bad
    convergence, floating point over- or underflow, out of memory, etc).
    So let's add missing checks.
    
    Thanks to Ernst Moritz Hahn for a bug report.
    (cherry picked from commit 9993a7aac97abf383624fc5dae4beecb29531fbd)

-----------------------------------------------------------------------

Summary of changes:
 ginac/inifcns.cpp  |   38 ++++++++++++++++++++++++++++++++------
 ginac/integral.cpp |    2 --
 ginac/power.cpp    |    2 ++
 3 files changed, 34 insertions(+), 8 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations