Preparing for release 1.6.0.

This patch fixes a bug on machines where char is unsigned by default, by
extending the type of clifford_max_label to include all 257 possible
return values. Thanks to Martin Guy for the bug report and patch.

Removed autogen stuff from the configuration.

Update the supported platforms/compilers list.

Parser: don't bother to generate 3 (C++) functions with autogen.

Fix a typo in the GCD testcase.

Limiting the costly symmetrization tests inside simplify_indexed() to
cases where at least one antisymmetric or cyclic non-free index is
involved. Thanks to P.G.Clark for reporting the problem.

Changed naming convention for the library. Now, it is only libginac.so
without the release version included (instead of libginac-1.5.so, for
example). Since the previous commit broke the ABI, we are free to
implement this long planned change now.

Fixed a bug introduced in last commit.

Before, sqrt(2)*x used to be a polynomial in x.
Now, it is a polynomial in x again.

Fixed a bug in is_polynomial() that caused expressions like
sqrt(x*x+1)*sqrt(x+1) to be wrongly identified as polynomials in x.
Thanks to Florent Hivert for reporting.

./configure now gives more information/warnings about missing utilities.

Avoiding a spurious missing ginac_parser.h error when doing a parallel
build (make -j..).

The patch improves the run time at the expense of using more RAM in some
situations. Please note: it doesn't improve the actual algorithm
(iteration over all permutations). Thanks to Alexei Sheplyakov.

Fix mul::conjugate().

Overwrite conjugate() for mul objects because the base class's conjugate
function is incorrect at branch cuts when exponents are fractional (roots).
This has been reported as Sage #10964.

While at it, fix some funny indentation and remove unneeded tests.

Updated the news about changes done since the last release (2010-07-06).

Add conjugate() methods to functions cosh, sinh, tanh.

Extend copyright to 2011.

Fix compilation with clang.

This resolves some depending names that GCC generously accepts.

Don't try to tie the library version to the package version number.

Merge branch 'master' of git://github.com/AlexeiSheplyakov/GiNaC.tmp

Merge branch 'msvc.support' of git://github.com/AlexeiSheplyakov/GiNaC

* 'master.msvc.support' of git://github.com/AlexeiSheplyakov/GiNaC:
  Omit extra qualification (as in struct foo f() vs foo f()).
  [msvc] msvc cannot handle string constants above 16k
  [msvc] Yet another compiler bug work around.
  [msvc] Work around strange scoping and name mangling rules.
  Add few defines for msvc (__func__, __alignof__).
  symmetry::compare_same_type(): const-correctness fix
  clifford: fix a few GCCisms (or, not).

Don't try to tie the library version to the package version number.

Use curret:release:age to indicate ABI changes instead. Hard-code LT_RELEASE
to 1.5 to avoid spurious SONAME change (current code is binary-compatible
with GiNaC 1.5.8).

Merge branch 'ginac_1-5' of git://ginac.de/ginac

Use C style cast when converting void* into function pointer.

Building GiNaC 1.5.5 with GCC 3.4 fails with the following error:

libtool: compile:  ccache g++-3.4 -DHAVE_CONFIG_H -I. -I../../ginac -I../config -I/home/pc7135/varg/target/x86_64-linux-gnu/include -O2 -g -Wall -pipe -MT builtin_fcns.lo -MD -MP -MF .deps/builtin_fcns.Tpo -c ../../ginac/parser/builtin_fcns.cpp  -fPIC -DPIC -o .libs/builtin_fcns.o
../../ginac/parser/builtin_fcns.cpp: In function `GiNaC::ex (* GiNaC::encode_serial_as_reader_func(unsigned int))(const GiNaC::exvector&)':
/home/pc7135/varg/tmp/build/GiNaC/build-linux-gcc-3.4/ginac/../../ginac/parser/builtin_fcns.cpp|67| error: ISO C++ forbids casting between pointer-to-function and pointer-to-object
make[2]: *** [builtin_fcns.lo] Error 1

The C++98 standard [expr.reinterpret.cast] does not allow

reinterpret_cast<function_pointer>(void*)
reinterpret_cast<void*>(function_pointer)

But the ability to do so is important for a lot of practical uses. So soon
after the C++98 standard was approved, a language defect report was filed
on this topic, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#195
The result is that compilers will be allowed to support reinterpret_cast
conversions of function pointers to other (pointers) types, and vice a versa.
Such conversions work with *current* compilers (GCC 4.x), but don't work
with older ones, hence this patch.

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

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

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.

Fix the compliation error *for real*

Fixed memory leak.

Fixed the fix in commit f059ebe117d15292e0d262e6e8e232e835c7e33c.

Fixed dirty hack in parser to distinguish between serial numbers and pointers.

Fixed the parser such that it can read in user defined classes again.
Fixed default reader to parse also pow, sqrt and power.

Fixed cast that caused compile error on 64bit machines.

Allow user defined functions to be parsed.

This patch is an ugly hack that does the same as the commit
f38cbcd651246fb5c1294705d29399f3cbfddaf5
but without changing the ABI (so it can be used in ginac_1-5).

Revert "Changed the parser such that it understands all defined functions"

This reverts commit f38cbcd651246fb5c1294705d29399f3cbfddaf5, which
broke parsing user-defined classes.

Make symbol::name be initialized lazily.

This fixes symbol::get_name(), which returned an empty string instead of
"symbol" followed by the serial number if the symbol's name wasn't
specified in the constructor.

Thanks to Warren Weckesser for reporting this bug.
(cherry picked from commit f5abf61d2cb1a1d1809d270a24fa098575b172c4)

Make symbol::name be initialized lazily.

This fixes symbol::get_name(), which returned an empty string instead of
"symbol" followed by the serial number if the symbol's name wasn't
specified in the constructor.

Thanks to Warren Weckesser for reporting this bug.

[PATCH 2/2] chinrem_gcd: return correct integer content when GCD is a number.

This patch fixes a silly typo and makes chinrem_gcd work correctly with
polynomials which are "almost" (up to an integer coefficient) relatively
prime.

Thanks to Ernst Moritz Hahn for a bug report and a test case.
(cherry picked from commit 00507499530d90533cf029bd503be326d9018138)

[PATCH 1/2] extract_integer_content: check for rational numbers properly.

Commit 3d09388a (titled as `[bugfix] chinrem_gcd: handle polynomials over
rationals properly.') broke extract_integer_content: now it always returns 1.
The check for rational `integer_contnent' introduced by that commit is wrong
(since integers is a subset of rationals). Rewrite the check proprerly.
(cherry picked from commit f0fb303711b4334ce59f7da63bfa7cb49f46265f)

[PATCH 2/2] chinrem_gcd: return correct integer content when GCD is a number.

This patch fixes a silly typo and makes chinrem_gcd work correctly with
polynomials which are "almost" (up to an integer coefficient) relatively
prime.

Thanks to Ernst Moritz Hahn for a bug report and a test case.

[PATCH 1/2] extract_integer_content: check for rational numbers properly.

Commit 3d09388a (titled as `[bugfix] chinrem_gcd: handle polynomials over
rationals properly.') broke extract_integer_content: now it always returns 1.
The check for rational `integer_contnent' introduced by that commit is wrong
(since integers is a subset of rationals). Rewrite the check proprerly.

Omit extra qualification (as in struct foo f() vs foo f()).

According to the Standard extra qualification like this

struct foo;
struct foo f();

is valid. However msvc does not accept such a code. So let's omit extra
qualification, as in

struct foo;
foo f();

(it's still valid C++) to make msvc happy.

[msvc] msvc cannot handle string constants above 16k

So let's split them.

[msvc] Yet another compiler bug work around.

msvc does not include the exprseq::info() method, giving unresolved symbols
when linking. Apparently adding a dummy function "fixes" the problem.

[msvc] Work around strange scoping and name mangling rules.

1. msvc creates different symbols for a variable declared in
   a namespace scope and (the same variable) in a class method
   scope. That is,

   // util.cpp
   namespace GiNaC {
   extern const ex _ex0; // [1]
   }
   // ex.h
   namespace GiNaC {
   class ex {
   public:
          bool is_zero() {
                extern const ex _ex0;
                // mangled name of _ex0 is different that of [1]
          }
   };
   }

2. The mangled names for cv-qualified and cv-unqualified versions
   of a type are different (which violates the requirements stated
   in [basic.type.qualifier])

These msvc's "features" cause linking failures due to unresolved
external symbols.

Solution:
1. Declare variables (_ex0) in the GiNaC namespace scope (for msvc only).
2. Add corresponding cv-qualifier(s).

Add few defines for msvc (__func__, __alignof__).

msvc does not provide the __func__ macro (which is required by C99,
btw). Also it has __alignof instead of __alignof__.

symmetry::compare_same_type(): const-correctness fix

The method in question is const, therefore one should use const_iterator
to access indices. Some compilers (for instance, msvc) are very strict
about this, and won't accept (invalid) code using non-const iterator.

clifford: fix a few GCCisms (or, not).

Some compilers (in particular, msvc) choke on `or' and `not'. Use
standard ! and || instead.

[bugfix] chinrem_gcd: handle polynomials over rationals properly.

* extract_integer_content():
  integer_content() can also return a rational number, e.g if the expression
  is a polynomial over rationals (in this case expr/content is polynomial
  over integers with integer content being 1). Therefore check if
  integer_content() is really an integer (and if it's not just return 1,
  GCD for polynomials over a field is defined up to arbitrary element of
  the field).

  This fixes possible segfault when computing GCD of polynomials over
  rationals (this is not theoretical, see the added test case).

Thanks to Ernst Moritz Hahn for reporting this bug.
(cherry picked from commit 3d09388a8ea144a19949c216fae43ccba92e47aa)

[bugfix] chinrem_gcd: handle polynomials over rationals properly.

* extract_integer_content():
  integer_content() can also return a rational number, e.g if the expression
  is a polynomial over rationals (in this case expr/content is polynomial
  over integers with integer content being 1). Therefore check if
  integer_content() is really an integer (and if it's not just return 1,
  GCD for polynomials over a field is defined up to arbitrary element of
  the field).

  This fixes possible segfault when computing GCD of polynomials over
  rationals (this is not theoretical, see the added test case).

Thanks to Ernst Moritz Hahn for reporting this bug.

power::series(): handle someg (trivial) singularities of the exponent...

... so GiNaC can expand expressions like

cos(x)^(sin(x)/x) // (x -> 0)
(1 + x)^(1/x) // x -> 0

and so on.

[Reported by Camille Gillot.]
(cherry picked from commit 079c558d4f9758cd2777a2808a02d64cb1f70c8e)

power::series(): handle someg (trivial) singularities of the exponent...

... so GiNaC can expand expressions like

cos(x)^(sin(x)/x) // (x -> 0)
(1 + x)^(1/x) // x -> 0

and so on.

[Reported by Camille Gillot.]

mul: algebraic_subs_mul(), has(): don't write beyond the end of array

algebraic_match_mul_with_mul() iterates over operands of mul, that is

for (size_t i=0; i<e.nops(); ++i)

However, the size of arrays (`vectors' in STL speak) passed to this
function is seq.size(), which is nops() - 1 for any mul object. Thus
algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually
it's not a problem, since any reasonable implementation of std::vector<bool>
packs booleans into ints (or longs). However, some STL implementations
(in particular, the one shipped with msvc) are more picky, and access
beyond the vector<bool> limits results in a segfault. Therefore let's
play safe and allocate proper number of elements (that is, nops()) for
those arrays (subsed and currsubsed).
(cherry picked from commit cbb93fadabbd56ba006902967b15b2b2aebb037c)

mul: algebraic_subs_mul(), has(): don't write beyond the end of array

algebraic_match_mul_with_mul() iterates over operands of mul, that is

for (size_t i=0; i<e.nops(); ++i)

However, the size of arrays (`vectors' in STL speak) passed to this
function is seq.size(), which is nops() - 1 for any mul object. Thus
algebraic_match_mul_with_mul() accesses beyond the arrays limit. Usually
it's not a problem, since any reasonable implementation of std::vector<bool>
packs booleans into ints (or longs). However, some STL implementations
(in particular, the one shipped with msvc) are more picky, and access
beyond the vector<bool> limits results in a segfault. Therefore let's
play safe and allocate proper number of elements (that is, nops()) for
those arrays (subsed and currsubsed).

Avoid infinite loop when unarchiving realsymbol and possymbol.

symbol::read_archive(): explicitly set status_flags::evaluated (and
status_flags::expanded) on object being unarchived. These flags get
reset by basic::operator=(const basic&) for realsymbol and possymbol,
and nothing sets (except symbol ctor), so automatic evaluation never
terminates (or rather, terminates due to a stack overflow). Therefore
it's necessary need to set status_flags::evaluated explicitly.

Thanks to Markus Fröb for a bugreport and a test case.
(cherry picked from commit e99d0d58c1bbaa8ee73e4a90a90aa1086f2f813d)

Avoid infinite loop when unarchiving realsymbol and possymbol.

symbol::read_archive(): explicitly set status_flags::evaluated (and
status_flags::expanded) on object being unarchived. These flags get
reset by basic::operator=(const basic&) for realsymbol and possymbol,
and nothing sets (except symbol ctor), so automatic evaluation never
terminates (or rather, terminates due to a stack overflow). Therefore
it's necessary need to set status_flags::evaluated explicitly.

Thanks to Markus Fröb for a bugreport and a test case.

ncmul::eval(): don't write beyond the end of the vector.

Make sure add::eval() collects all numeric terms.

Apparently, add::eval() assumed that none of the elements of its epvector
has a numeric rest. However, nothing guarantees that -- in particular
evalchildren() doesn't (and actually cannot) do so. Since there are many
places where a new add is constructed directly from an epvector, enforcing
this doesn't make sense either. One example where it did fail was found by
Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.

Thanks to Burcin Erocal for reporting this bug.
(cherry picked from commit e08cda1854bdb82f6706ec269233577690ae00e4)

Make sure add::eval() collects all numeric terms.

Apparently, add::eval() assumed that none of the elements of its epvector
has a numeric rest. However, nothing guarantees that -- in particular
evalchildren() doesn't (and actually cannot) do so. Since there are many
places where a new add is constructed directly from an epvector, enforcing
this doesn't make sense either. One example where it did fail was found by
Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.

Thanks to Burcin Erocal for reporting this bug.

Be more careful about final top-level substitution.

Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
substitution is wrong in the general case. On the other hand, the intent
is to syntactically substitute functions of a given kind etc. This patch
suppresses the final top-level substitution unless the intermediate result
is a container.

Thanks to Burcin Erocal for reporting this bug (originally described by
Kees van Schaik on sage-support@googlegroops.com).

Be more careful about final top-level substitution.

Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
substitution is wrong in the general case. On the other hand, the intent
is to syntactically substitute functions of a given kind etc. This patch
suppresses the final top-level substitution unless the intermediate result
is a container.

Thanks to Burcin Erocal for reporting this bug (originally described by
Kees van Schaik on sage-support@googlegroops.com).

Fix autoconf warning about AC_INIT use.

Apparently, autoconf doesn't like the angle brackets in the bug-report
argument any more. It comlains "not a literal: <ginac-list@ginac.de>".
So let's remove it. And while at it, also provide tarname and url
arguments.

Fix autoconf warning about AC_INIT use.

Apparently, autoconf doesn't like the angle brackets in the bug-report
argument any more. It comlains "not a literal: <ginac-list@ginac.de>".
So let's remove it. And while at it, also provide tarname and url
arguments.

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)

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)

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)

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)

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.

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.

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)

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.

Preparing for release 1.5.8.

Removed trailing spaces.
(cherry picked from commit dbde7117e88ba61597d6fee18615fe396c291a87)

Removed trailing spaces.

Texinfo interprets @strong{Note...} as a cross reference and gives a
warning about it. Changed the text to avoid this.
(cherry picked from commit 7769ce49235ed6510785baa0a29801e3a59b563e)

Texinfo interprets @strong{Note...} as a cross reference and gives a
warning about it. Changed the text to avoid this.

Parser: handle abbreviations as advertized in the manual.

The following example from the tutorial

GiNaC::symbol x, y;
GiNaC::symtab table;
table["x"] = x+log(y)+1;
GiNaC::parser reader(table);
GiNaC::ex e = reader("5*x3 - x2");

fails with the following exception:

terminate called after throwing an instance of 'std::invalid_argument'
what(): find_or_insert_symbol: name "x" does not correspond to a symbol

Remove silly checks from find_or_insert_symbol, and fix its return value
(should be ex, not symbol).

Parser: handle abbreviations as advertized in the manual.

The following example from the tutorial

GiNaC::symbol x, y;
GiNaC::symtab table;
table["x"] = x+log(y)+1;
GiNaC::parser reader(table);
GiNaC::ex e = reader("5*x3 - x2");

fails with the following exception:

terminate called after throwing an instance of 'std::invalid_argument'
what(): find_or_insert_symbol: name "x" does not correspond to a symbol

Remove silly checks from find_or_insert_symbol, and fix its return value
(should be ex, not symbol).

Be more careful with conjugate(f(x)) -> f(conjugate(x)).

That identity is correct for holomorphic functions, but we have to be
careful with some functions not being holomorphic everywhere. On branch
cuts, it is wrong. For a discussion, see:
<http://www.ginac.de/pipermail/ginac-list/2010-April/001601.html>.

This patch changes the default behavior of user-defined functions. From
now on, a user-defined conjugate_func must be registered, in order to
evaluate conjugate(f(x)) -> f(conjugate(x)). This patch also adds such
functions for most initially known functions.

Be more careful with conjugate(f(x)) -> f(conjugate(x)).

That identity is correct for holomorphic functions, but we have to be
careful with some functions not being holomorphic everywhere. On branch
cuts, it is wrong. For a discussion, see:
<http://www.ginac.de/pipermail/ginac-list/2010-April/001601.html>.

This patch changes the default behavior of user-defined functions. From
now on, a user-defined conjugate_func must be registered, in order to
evaluate conjugate(f(x)) -> f(conjugate(x)). This patch also adds such
functions for most initially known functions.

Fix dangerous iterator use.

This was detected by cppcheck and reported by Martin Ettl <ettl.martin@gmx.de>.

Fix dangerous iterator use.

This was detected by cppcheck and reported by Martin Ettl <ettl.martin@gmx.de>.

pgcd(), chinrem_gcd(): use appropriate definition of the degree.

Effect: fixes (rare) GCD miscalculation.

pgcd() treats polynomials Z_p[x_0, ..., x_n] as R[x_0, ..., x_{n - 1}], where
R = Z_p[x_n]. Therefore one should use correct definition of the degree
(i.e. compute it w.r.t. x_0, ..., x_{n-1}, but NOT w.r.t. x_n!).

One should use appropriate definition of degree (that is, w.r.t.  x_0, ..., x_n)
in chinrem_gcd() too.

Thanks to Aless Lasaruk for a bug report.

Added `degree_vector' utility function.

It's a generalization of degree(expr, var) for multivariate polynomials.

primpart_content: correctly handle monomials.

Impact: fixes (rare) incorrect gcd calculation and (potential) segfault.

Thanks to Aless Lasaruk for a bug report.

pgcd(): avoid infinite loop if the first GCD candidate coincides with GCD

136 if (H_lcoeff.is_equal(lc_gcd)) {
137 if ((Hprev-H).expand().smod(pn).is_zero()) // (*)
138 continue;

The check (*) can result in infinite loop if the (very) first GCD candidate
gives the correct GCD: any subsequent iterations give the same result, so
Hprev and H will be equal (hence the infinite loop). That check is not very
useful (AFAIR I was trying to avoid extra division checks), so let's remove it.

pgcd(), chinrem_gcd(): use appropriate definition of the degree.

Effect: fixes (rare) GCD miscalculation.

pgcd() treats polynomials Z_p[x_0, ..., x_n] as R[x_0, ..., x_{n - 1}], where
R = Z_p[x_n]. Therefore one should use correct definition of the degree
(i.e. compute it w.r.t. x_0, ..., x_{n-1}, but NOT w.r.t. x_n!).

One should use appropriate definition of degree (that is, w.r.t.  x_0, ..., x_n)
in chinrem_gcd() too.

Thanks to Aless Lasaruk for a bug report.

Added `degree_vector' utility function.

It's a generalization of degree(expr, var) for multivariate polynomials.

primpart_content: correctly handle monomials.

Impact: fixes (rare) incorrect gcd calculation and (potential) segfault.

Thanks to Aless Lasaruk for a bug report.

pgcd(): avoid infinite loop if the first GCD candidate coincides with GCD

136 if (H_lcoeff.is_equal(lc_gcd)) {
137 if ((Hprev-H).expand().smod(pn).is_zero()) // (*)
138 continue;

The check (*) can result in infinite loop if the (very) first GCD candidate
gives the correct GCD: any subsequent iterations give the same result, so
Hprev and H will be equal (hence the infinite loop). That check is not very
useful (AFAIR I was trying to avoid extra division checks), so let's remove it.

Fix URL of CODA.

Fix URL of CODA.

Fix memory leak in excompiler due to use of wrong operator delete.

This was reported by Martin Ettl <ettl.martin@gmx.de>.

Fix memory leak in excompiler due to use of wrong operator delete.

This was reported by Martin Ettl <ettl.martin@gmx.de>.

Explicit function disambiguation.

This is necessary for compilers where the hyperbolic and the tgamma function
templates are pulled in from <cmath> and compete with GiNaC's function
templates. GCC 4.4 and 4.5 need this, when compiling with -std=cxx0x.

Explicit function disambiguation.

This is necessary for compilers where the hyperbolic and the tgamma function
templates are pulled in from <cmath> and compete with GiNaC's function
templates. GCC 4.4 and 4.5 need this, when compiling with -std=cxx0x.

Fix weird ctor invocation syntax.

This patch is required for GCC-4.5.

Fix weird ctor invocation syntax.

This patch is required for GCC-4.5.

Preparing for release 1.5.7.

Products (class mul) now answer correctly to info_flags::negative and
info_flags::negint.
(cherry picked from commit 8a30acc990818792ec4e8f8f4d48f5dd8286dbed)

Products (class mul) now answer correctly to info_flags::negative and
info_flags::negint.