Make add::eval(), mul::eval() work without compromise.

If a user asks to evaluate an object, the expectation is that the
library returns an evaluated, canonical expression. Everything else is
a bug. (It doesn't matter whether the user asks explicitly or by
assigning to an ex.) It turns out that it was possible to construct
objects which didn't fully evaluate. This patch fixes this by making
eval() a little bit more careful.

This obsoletes the need to go through combine_ex_with_coeff_to_pair()
when constructing an epvector that is then used to construct an add
or mul. (Alas, this was omitted frequently enough...)

Improve method of setting status_flags::dynallocated.

There seems to be no way to obsolete the need to mark an object derived
from basic and handled by ex as being 'on the heap', at least none that
doesn't have significant performance impact. Having said that, this
patch aims at making this process simpler and more intuitive.

Where, before, one would return from a function returning an ex with
        return (new mul(a, b))->setflag(status_flags::dynallocated);
this patch lets us return with
        return dynallocate<mul>(a, b);
which should be much clearer. In any case, it involves less typing.

The two points where the status_flags::dynallocated are set are now
  * the dynallocate<B>(args...) template function and
  * the virtual duplicate() member functions.

This patch rolls out the new functionality throughout the library.

Remove accidentally pushed binary.

In commit 79cad108, a compiled binary from the test suite was accidentally
added and pushed. Sorry.

Rename array of precomputed data in test suite.

Reason: C++17 may introduce a std::data<> template. Right now, the GCC 6.0
prerelease bails out at this code, when compiler with -std=c++17.
<http://en.cppreference.com/w/cpp/iterator/data>

Use neseted initializer lists to construct matrix objects.

Add constructor of initializer_list<initializer_list<ex>> to matrix.
Use this syntax where, previously, ctor from comma-separated list of
elements was used. Deprecate the ctor from comma-separated list.

Note: The output format '[[a,b],[c,d]]' and ginsh syntax are
unchanged because lists are printed '{a,b,c}' and a matrix is not a
list of lists.

[build] Update scripts for correct rpath for linking with CLN.

Use up-to-date files from GNU gettext 0.19.6.

Use initializer lists to construct container<>, lst.

Add constructor of initializer_list<ex> to container<C<ex>>. In
particular, this means that we can finally declare lst objects as
lst{a,2*b,2}. Convert GiNaC to this syntax throughout. Deprecate
the old constructors taking 1..16 ex parameters and the ones from
comma seaparated lists (without braces).

Infrastructure: Update baseline language check M4 macros.

Use the more general ax_cxx_compile_stdcxx.m4 macro from gnu.org
instead of the old ax_cxx_compile_stdcxx_11.m4.

Make ample use of the contextual keyword 'override'.

This patch adds the C++11 contextual keyword 'override' to every overridden
virtual function declaration except where that would incur macro duplications.
Along the way, it fixes some comments about member functions 'virtuality'.

Standard header cleanup.

Sanitize some standard headers, remove include directives of unused
headers, complete configure check for used standard headers.

Replace idx_is_not functor by a C++11 lambda.

In power::expand_add(), don't reserve excess monomial sizes.

There is no need to reserve n terms in each of the monomials of the
result of power(+(x,y,z...;0),n): We can compute it exactly as the
number of nonzero exponents in the multinomial expansion. The good
thing is that this counting is the same for each composition of a
partition, so it can be hoisted out of the loop over compositions.

Make specialized power::expand() helpers static member fuctions.

The class power member functions expand_add(), expand_add_2(), and
expand_mul() do not access any member variable of class power. (In
fact, the only reason not to hide them entirely is that they invoke
protected members of classs expairseq, add, and mul which requires
them to be friends of these classes.)

Tutorial: how to create noncommutative symbols?

This seems to be frequently asked:
<http://www.ginac.de/pipermail/ginac-devel/2015-November/002213.html>

Avoid some explicit copying of STL containers.

mul::can_make_flat(): Finish ancient unfinished code.

This makes mul(expairseq({a*b,2},{b})) construct the canonical
mul(expairseq({a,3},{b,2})). Normally, such term rewriting is done
by the .eval() methods, but this is not done when a plain object of
a class derived from basic is constructed.

unit_matrix(r,c) can return an evaluated matrix object.

Make (a+b+c+...)^n work for huuuge terms.

This fix is neccessary for results exceeding 2^31 terms. While at it,
also restructured power::expand_add_() a bit to look more like the
more general power::expand_add().

Convert some more ctors from copying to moving STL containers.

Replace static const variables with constexpr, where applicable.

Fix some pedantic compiler warnings.

Found with CLang++ -Wall. (There remain some more, but these are
more ugly to fix.)

Replace GiNaC::ToString() with std::to_string().

And, while at it, also make CMake exercise the new real_imag exam
introduced last week and document successful build with GCC-4.8.

Use C++11 'nullptr' where applicable.

Remove C++89 workaround for closing angle brackets in nested templates.

Remove 'discardable' option from ctors of container and derived classes.

The whole idea of this was to allow the ctor to pilfer the data from the
constructed-from object, which is precisely the move semantics which
C++11 supports with rvalue references.

Add trivial shortcuts in expair plumbing of class add.

These little shortcuts in add::split_ex_to_pair(ex) and in
add::combine_ex_with_coeff_to_pair(ex, ex) avoid the creation of
new ex objects. These pieces of code are executed so often that this
patch speeds up GiNaC by 5-10%, depending on test.

Fix little missed optimization.

Replace dynamic throw() with static noexcept operator.

Add some minor optimizations.

Speed up power::real_part() and power::imag_part().

Add special case for real base and exponent (not just integer exponent).
Improve special case for integer exponent by explicitly constructing
the result using the Binomial expansion.
Add a test case for real/imaginary part expansion.

Use AX_CXX_COMPILE_STDCXX_11 macro to force C++11 compilation.

Fix most remaining GCC compiler warnings.

Move ctors for classes matrix and pseries.

Use C++11 range-based foor loops and auto, where possible.

Update documentation of prerequisites.

Replace use of NULL by C++11 nullptr.

Remove dependence on depreacted std::auto_ptr<T>.

Most of the auto_ptr were introduced to avoid copying. C++11 supports
move semantics for this. Some other can be replaced by std::unique_ptr<T>.

Remove support for Cint.

Remove unfinished code for hash table-based expairseq.

This is unfinished code by A.F. Later generations don't ever
seem to have tinkered much with it.  ;-)

Fix make check with g++ -std=c++11.

Our template function log() returning an object of type GiNaC::function
turns out to compete with a template from a libstdc++ header. We have
to help the compiler a bit.

Fix some apparent typos and misindentations 2.

(Formatting should comply with http://www.cebix.net/indentation.html.)

Fix algebraic power::has() for larger integer exponents.

There is no need to overflow integers in (x^2147483648).has(x^2).

Include crc32.h only if needed.

This shuts up a compiler warning about unused static function crc32.

Remove unused variable.

This shuts up a compiler warning.

Fix parser example in tutorial.

Thanks to Jean-Michaël Celerier for pointing this out.

Fix some apparent typos and misindentations.

Finalizing release 1.6.5.

Fix bug in PolyLogs of rational numbers.

Thanks to Alexander Hasselhuhn for reporting this bug.

Speed up pow(+(...),n).expand() where n>2.

This new algorithm is faster than the old one because it re-uses
multinomial coefficients as much as possible.

Fix pow(+(...),2).expand().

Due to a failure to expand result terms, expand((sqrt(1+x)+y*sqrt(1+x))^2)
returned 1+y^2+x+x*y^2+2*y*(1+x). Note that 2*y*(1+x) was not expanded
to 2*y+2*y*x.

Finalized 1.6.4 release.

Fix pow(+(...),2).expand().

Due to a failure to recombine coeffs and rests to expairs,
expand((x+sqrt(2)*x)^2) returned x^2+2*x^2+2*sqrt(2)*x^2. The
2*x^2 term was not combined with the x^2 term to 3*x^2 because it
was not the canonical expair [[x^2,2]] but rather [[2*x^2,1]].

Thanks to Isuru Fernando for the bugreport.

Add test cases for improved abs(arg).

Exam the evaluations abs(±sqrt(p)) -> sqrt(p) for p > 0.

Improve abs(arg).

Make abs(arg) return -arg if arg is negative or if -arg is known to be
nonnegative.

Fix pow::info(info_flags::nonnegative).

This function call was missing the case where a positive base is raised
to a real power (where pow::info(info_flags::positive) correctly returned
true).

Fix mul::info(info_flags::nonnegative).

Due to an obvious Boolean inversion, this function call always
returned the wrong answer.

Make power::expand() (x*p)^c -> x^c * p^c, if p>0.

This expansion seems to be helpful in many cases.

Make compile_ex() work with CMake.

Infrastructure fixes to make CMake find libdl and make ginac-excompiler
listen to the $CXXFLAGS environment variable.

Improve normalization with nested functions.

normal() fails to fully normalize expressions where nested functions occur
multiple times because replace_with_symbol() searches repl for an
original expression but inserts into repl the substitued expression. Then
the repeated search does not work and a new symbol is introduced.

This patch fixes that by searching for the expression with the repl
substituted instead of for the original expression.

Fixing index in tutorial.

The index entry for clifford::get_metric() did not work, change it to get_metric().

Signed-off-by: Vladimir V. Kisil <kisilv@maths.leeds.ac.uk>

Explicit derivation of functions.

Some function cannot be cleanly differentiated through the chain rule.
For example, it is natural to define derivative of the absolute value as

(abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f)

This patch adds a possibility to define derivatives of functions in this way.
In particular the derivative of abs(), Order(), real_part(), imag_part() and
conjugate() are defined.

For example, conjugate of a derivative with respect of a real symbol
If x is real then U.diff(x)-I*V.diff(x) represents both
conjugate(U+I*V).diff(x) and conjugate((U+I*V).diff(x))
Thus in this patch we use the rule

conjugate(f)'=conjugate(f')

for a derivative with respect to the real symbol.

Signed-off-by: Vladimir V. Kisil <kisilv@maths.leeds.ac.uk>

Put a reference on eta function into tutorial.

Happy new year!

Small optimization in simplify_indexed.

If the new expression is product again then we call the same function return
simplify_indexed_product() rather than the its mother implify_indexed().

Evaluate abs(z)^(2n) -> z^n * conjugate(z)^n.

Finalized 1.6.3 release.

Updated NEWS file, moved some comments so Doxygen won't be confused.

Prepare for 1.6.3 release.

Update copyright statements.

The FSF has moved (long ago).

Update some its postal address in some remaining places.

Fix log() error in multiple polylog G.

Tobias Huber reported the following bug:
> G({-0.18784426860496276*I,-0.1579006477353911*I,+0.18784426860496276*I,-0.18784426860496276*I},1);
log_eval(): log(0)

The problem is the sorting operation in G_do_trafo. This operation should
1) put the elements in increasing order of |x|
2) put equal elements next to each other (which then will avoid the log(0) problem).

The current code fails for goal 2) if we have complex numbers of equal absolute
value, one number occuring more than once, in an initial order like in the example
above:
Entries 1,3,4 of the list all have the same absolute value, entries 1 and 4 are
equal. In the sorting operation 1 and 4 should be put next to each other.
Previously, the sorting operation would give 2,1,3,4. What we would like to have
is either 2,1,4,3 or 2,3,1,4. It is clear that the key for the sorting operation
cannot be |x| alone. If |x1|=|x2| we have to use the phase as well.

This patch takes the phase into account in the sorting.

Fix evaluation of some G-polylogs.

This patch corrects and supersedes the patches
97ef604e "G_numeric: fix numeric evaluation with trailing zeros and y != 1."
and
9e80b0d3 "G_numeric: fix evaluation with y == 1".

The original motivation for 97ef604e was to make sure that Hoelder convolution
is only used if there no trailing zeros.

Patch 97ef604e delegated the case of trailing zeros to G_do_trafo, which correctly
removes the trailing zeros, but in addition also performed the transformation
described in sect. 5.3 of hep-ph/0410259 ("convergence transformation").
The inappropriate call of the convergence transformation is the cause of the new bug
reported at http://www.cebix.net/pipermail/ginac-list/2014-September/002011.html

The patch 9e80b0d3 cures the symptons mentioned in the above bug report,
but fails for other cases, like evalf( G({-2,2,-2,0},2) ).

What should be done is the following: If trailing zeros are detected in G_numeric,
these should be removed and the result should be returned to G_numeric. The
routine G_numeric decides then what to do next: either calling the convergence
transformation, or Hoelder convolution or direct summation. What is needed is a
subroutine, which just removes trailing zeros, but does not perform the convergence
transformation.

With the present code the minimal modification to achieve this goal is to add an
additional boolean parameter flag_trailing_zeros_only to G_do_trafo (and its
dependent sub-routines), so G_do_trafo can be called for the removal of trailing
zeros only.

This patch implements this and uses G_do_trafo to remove trailing zeros only for
the case at hand.

G_numeric: fix evaluation with y == 1

Do apply Hoelder convolution if y == 1 even if there are trailing zeros.
Fixes the regression introduced by commit 97ef604e ("G_numeric: fix
numeric evaluation with trailing zeros and y != 1.")

Add more ex::is_polynomial() tests

Improves commit 92da4c16 ('[bugfix] ex::is_polynomial(x): fix miscomputations')
a little bit.

Providing default (un)archiving for cliffordunit class.

Signed-off-by: Vladimir V. Kisil <kisilv@maths.leeds.ac.uk>

[bugfix] ex::is_polynomial(x): fix miscomputations

The function power::is_polynomial(x) sometimes returned false,
even if x did not occur in the power object.

Thanks to Rubel Zilibowitz for reporting this bug.

Similarly, mul::is_polynomial(x) sometimes returned true, even
if x occurred only in the denominator of a rational function.

The function mul::is_polynomial(x) does a simpler version of
power::is_polynomial(x) on its factors. (It's simpler because the
exponents cannot be functions of x.)

Fix example of symmetrization in tutorial.

The old example was illegal C++. Thanks to Rubel Zilibowitz for
reporting this error.

[bugfix] log_series: avoid infinite recursion

Check if the argument is on a branch cut check if it actually depends
on the expansion variable before trying to expand around a different
point in order to avoid the infinite recursion (or rather a segfault
due to a stack overflow).

Thanks to Mario Prausa for a bugreport.

Fix an infinite loop in factor_multivariate.

Make sure the leading coefficient is really factorized (take care of
the integer content).

G_do_hoelder: fix the transformation of the imaginary part.

The G_do_hoelder function transforms the arguments as z -> 1-z.
If z has an imaginary part, the sign of the imagniary part transforms
as s -> -s.
In the special case where z is real and > 1, the transformed value is
real and < 0. For (transformed) real negative values of z the sign of
the imaginary part is not relevant (there are no branch cuts). The code
requires that in this case the sign takes the default value +1.
This is now fixed.

G_numeric: fix numeric evaluation with trailing zeros and y != 1.

Make sure G_numeric makes use of scaling relation (G_do_hoelder) only if
there are no traling zeros. Use G_do_trafo otherwise (which can handle
trailing zeros).

[docs] remind users tho send EOF marker when doing input from cin.

The example program waiting infinitely for EOF has confused at least one
user: <http://www.ginac.de/pipermail/ginac-list/2014-January/001983.html>

Binary compatibilty has been broken, update the library version.

commit 798d53ebb4da4e8e3865ed7bd7f31412fe2be3a7 (`Make it possible to override
info() for functions.') overrides the function::info() virtual method. This
breaks binary compatibility (adds a new entry in the middle of the vtable of
the `function' class).

The experimental proof of the above statement: ginsh linked with the previous
release of libginac segfaults if libginac.so is upgraded to the current
version.

Thereore bump the library version.

[build] Document that Python is required for building GiNaC.

[build] Fix `make pdf' for out of the source (auto* tools) build.

[build] Include the generated sources (function.{h,cpp}) into the tarball.

[build] Include CMake related files into the tarball.

[build] Include the helper scripts into the tarball.

check: auto* tools build: compile and run check_mul_info.

[build] ginsh: fix `make distcheck' failure.

log_eval: don't apply the log(x^p) -> p*log(x) rule.

Automatically transforming log(p^2) into 2 log(p) might be quite annoying.
Perhaps this transformation should be moved to expand() and applied only
if expand_options::expand_transcendental is specified.

Li_eval(): avoid the "numeric::operator>(): complex inequality" exception.

Basically the problem is that 1 + 0.0*I is equal to 1, but checking if
the former is positive results in the the "numeric::operator>(): complex
inequality" exception. This behavior is definitely inconsistent and should
be fixed.

As a work around teach Li_eval and convert_parameter_Li_to_H to explicitly
convert 1 + 0.0*I to 1 (and -1 + 0.0*I to -1, respectively).

[Alexei Sheplyakov: comment the code a little bit, otherwise it looks weird]

Fix S_num for arguments close to the sixth root of unity or its conjugate.

The method S_num within the Nielsen polylogs used to map the region
abs(x)<=1 && abs(x)>0.95 && abs(1-x)<=1 && abs(1-x)>0.95 infinitely many times
onto itself. This infinite recursion is now avoided.

This however reveals the next problem: The numerical convergence in this
region is very slow. Within the Nielsen polylogs there is no transformation
available to improve the convergence. However we can use the (1-x)/(1+x)
transformation within the harmonic polylogs. In order to avoid another
infinite recursion I have inserted a few hold()'s in the method H_evalf,
otherwise we would fall back immediately again to Nielsen polylogs. The hold()s
should have been there anyway.

Fix G3_evalf and G3_eval for real and negative x.

The user supplied signs of the imaginary parts are only relevant for x real
and positive. A negative sign in the case of x real and negative is irrelevant
(there is no branch cut) and led to wrong results. This is now avoided.

Within mLi_numeric, set signs of the imaginary parts correctly for G_numeric.

Avoid calling log(1-x) for x=1 in Li_projection.

Fix evaluation of log(p^a) -> a*log(p), if p>0 and a is real.

This evaluation was broken with commit e5c76f659e2e882d.

expairseq::match(): no side effects if match failed. Fixes spurious match failures.

> match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1))
FAIL

The reason is that expairseq::match() might assign a wildcard even if
the match fails. The first attempted submatch is sin(y)*exp(b) with
sin($0)*exp(a). It fails (as it should) but $0 == y gets assigned as
a side effect (which is wrong). Next submatch is sin(x)*exp(a) with
sin($0)*exp(a) (the same pattern as in the first submatch). This one
fails because of spurious $0 == y assignment.

Due to the unpredicatable term ordering the sequence of submatches might
be different and the match might succeed (as it should). This makes
debugging a bit more funny.

Signed-off-by: Matthias Dellweg <dellweg@tp1.uni-duesseldorf.de>
[Alexei Sheplyakov: figure out the cause of the problem, make a test case]

Expansion rules for exp(), log(), and abs().

exp(a + b) -> exp(a)*exp(b)
log(a*b) -> log(a) + log(b)
abs(z*w) -> abs(z)*abs(w)

log and exp are transformed only if expand_options::expand_transcendental
is given.

Signed-off-by: Vladimir V. Kisil <kisilv@maths.leeds.ac.uk>

Introduce expand_options::expand_transcendental.

In general expand() treats the argument as a rational expression (and
leave transcendental functions as they are). However sometimes it's
convenient to expand transcendental functions too, like

log(a*b) = log(a) + log(b)
exp(a + b) = exp(a)*exp(b)

Applying such transformation by default doesn't seem to be a smart idea
(think of log(p^2/mu^2) transformed to 2*log(p) - 2*log(mu)). Therefore
introduce expand_options::expand_transcendental. As the name implies expand()
tries to transform transcendental functions only if this flag is set.

Signed-off-by: Vladimir V. Kisil <kisilv@maths.leeds.ac.uk>

Keep CLang/libc++ happy.