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

[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  3f1026f0540e4e7ab86656389d09c2152269e6cf (commit)
       via  ab8da4fe0687969d124c2c3b3e6ce62a63376a0a (commit)
       via  dd19b7316b6eba5c49b6a4fb3503c504ec6c866a (commit)
       via  7f4a4ce46d799ba888b118dfdc8945c92a6c6d6f (commit)
       via  4ddeb4c2a625a069d71b510aab3ae53138670470 (commit)
       via  99c7ff6b72691f2eff30f94934d65d1ba7136ff9 (commit)
       via  554722426543a6e1445ead11167107a69fd21af9 (commit)
       via  aa1afbbdb118846cfc266a1d7a8d5188ac214e0e (commit)
       via  14aeeca161c7cc2d145b0778ac234341068efef1 (commit)
      from  5252d38313c423465b9bc37b0618cb8de96d0d4e (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 3f1026f0540e4e7ab86656389d09c2152269e6cf
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:03:15 2009 +0300

    modular_matrix: don't use STL iterators in {mul, sub}_col and friends.
    
    Not using STL iterators makes the code simpler and cleaner. Also we don't
    have to argue whether the standard ([lib.random.access.iterators]) imposes
    any pre/post-condictions on operator+=.
    (cherry picked from commit 59ec13895c97ffd74979a0b811a7571f6de56386)

commit ab8da4fe0687969d124c2c3b3e6ce62a63376a0a
Author: Jens Vollinga <jensv at nikhef.nl>
Date:   Sun Aug 9 23:38:48 2009 +0200

    Added get_builtin_reader() that parses only the builtin GiNaC functions
    and pow, sqrt, and power.

commit dd19b7316b6eba5c49b6a4fb3503c504ec6c866a
Author: Jens Vollinga <jensv at nikhef.nl>
Date:   Sun Aug 9 23:27:10 2009 +0200

    Fixed include of stdint.h (parser.cpp needs the header as well).

commit 7f4a4ce46d799ba888b118dfdc8945c92a6c6d6f
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:03:48 2009 +0300

    shaker_sort, permutation_sign: fix invalid use of STL iterators.
    
    According to the standard incrementing end(), and decrementing begin()
    are ill-defined operations (see [lib.forward.iterators],
    [lib.bidirectional.iterators]).
    (cherry picked from commit 694f839947982f5b12b6c629d5bab522c801630d)

commit 4ddeb4c2a625a069d71b510aab3ae53138670470
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:07:14 2009 +0300

    symmetry::calchash(): be careful to not dereference past-the-end iterator.
    (cherry picked from commit 526825bcee294cb20e37d8db6d5040ba0f8c428f)

commit 99c7ff6b72691f2eff30f94934d65d1ba7136ff9
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:06:36 2009 +0300

    check_parameter_G: fix pontential increment of end().
    
    Incrementing past-the-end iterator is not permitted by the standard, see
    [lib.input.iterators].
    (cherry picked from commit 49a44f7d55ec0d6686d3c32c7081a07d10c93274)

commit 554722426543a6e1445ead11167107a69fd21af9
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:02:47 2009 +0300

    G_eval: fix incorrect use of STL iterator.
    
    According to [lib.bidirectional.iterators] it's not OK to decrement
    an iterator pointing to the beginning of the sequence. Fortunately random
    access iterators provided by (current versions of) gcc/libstdc++ don't have
    this silly limitation, so the code which works with pointers works with
    iterators without any changes at all. However,
     - there's no guarantee that the current behavior won't change in the future
     - some non-GNU compilers are not that smart (i.e. the program segfaults
       upon when decrementing beginning-of-the-sequence iterator).
    (cherry picked from commit dda45abd8a2c408f8b3eb7959a10dfb2468ecc3a)

commit aa1afbbdb118846cfc266a1d7a8d5188ac214e0e
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 11:43:12 2009 +0300

    Fix the compliation error *for real* ... and restore performance
    
    Commit 8bf0597dde55e4c94a2ff39f1d8130902e3d7a9b (titled as 'Fixed the parser
    such that it can read in user defined classes again.') made the parser a bit
    slower, especially if the input contains many terms of user-defined type.
    The reason for that is quite simple: we throw and catch an exception every
    time we construct an object of user-defined type:
    
           // dirty hack to distinguish between serial numbers of functions and real
           // pointers.
           GiNaC::function* f = NULL;
           try {
                   unsigned serial = (unsigned)(unsigned long)(void *)(reader->second);
                   f = new GiNaC::function(serial, args);
           }
           catch ( std::runtime_error ) {
                   if ( f ) delete f;
                   ex ret = reader->second(args);
                   return ret;
           }
    
    Fortunately functions are aligned and we can use much more efficient
    technique to distinguish between serial and pointers to functions.

commit 14aeeca161c7cc2d145b0778ac234341068efef1
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Fri Aug 7 23:22:18 2009 +0300

    Fix the compliation error *for real*

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

Summary of changes:
 ginac/factor.cpp                |   60 +++++++++--------------
 ginac/inifcns_nstdsums.cpp      |    7 ++-
 ginac/parser/default_reader.tpl |  104 +++++++++++++++++++++++++++++++++------
 ginac/parser/parse_context.h    |   14 +++++-
 ginac/parser/parser.cpp         |   46 +++++++++++++-----
 ginac/symmetry.cpp              |    3 +-
 ginac/utils.h                   |   24 +++++++--
 7 files changed, 183 insertions(+), 75 deletions(-)


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