1. Bad performance. Parsing a sum seems to be O(N^{2 + a}) (a > 0).
For example, parsing a sum (actually, a univariate polynomial) of 32768
terms takes about 90 sec. on my box, parsing a sum of 10^6 terms takes
"eternity".
2. The user is expected to provide list of all symbols in the expression.
Often this is very annoying (and useless), sometimes it is not possible
at all.
3. Parser is not reentrant (bison *can* produce reentrant parsers, but that
won't solve other problems).
4. Parser is difficult to extend.

Since the new parser handles almost everything (useful) as the old one, let's
remove the latter.

Since the parser is recursive parse_* methods (in particular,
parse_binop_rhs()) does NOT check if the last unparsed token is valid.
Thus parse_expression() stops if it encounters an unknown token. That's
why parser::operator() needs to make sure nothing is left in the input
stream.

Convert helper functions G_do_hoelder and G_do_trafo in the same manner,
update all call sites. This should speed up numerical calculation of
multiple polylogarithms a little bit, and reduce the memory usage.

expairseq::match(): remove the code which works around basic::match bug.

basic::match() used to have side effects in a case of a failed match. As
a result of that bug exparsed::match did not work correctly in some cases,
see [1] for more details. These false negatives were worked around by [2].
Now that match() has no unwanted side effects [3] we don't need any work
arounds any more.

The argument of golden_ratio_hash() is as an integer of the same size as
a void* pointer. Unfortunately ISO C++ 98 does not provide suitable typedef.
Hence

* use <stdint.h> if available and define p_int to uintptr_t. Note: AC_PROG_CC
already checks for this header, so no extra checks are necessary.
* as a fallback define p_int to be unsigned long, this works on most systems
I know of (the only exception is woe64).

GiNaC allocates memory for static objects (i.e. flyweights, remember tables,
etc), but doesn't free it. This is OK if the program lifetime matches libginac
lifetime, since the OS will reclaim that memory anyway.
However, if the program lifetime is different from that of libginac, this
turns into a memory leak. This happens if someone dlopen's libginac.so, and
dlclose's it later on (read: if someone uses GiNaC via scripting language
bindings).

* Move crB and crG variables into initcX function (the only user of these
variables).
* Pass crX coefficients to crandall_Y_loop instead of using a global variable.
* While at it make crandall_Y_loop and initcX functions static.

GiNaC tries to avoid expanding expressions while computing GCDs and applies
a number of heuristics. Usually this improves performance, but in some cases
it doesn't. Allow user to switch off heuristics.

Part 5:

* gcd(): don't use heuristic GCD algorithm if gcd_options::no_heur_gcd
flag is set.
* gcd(): don't handle partially factored expressions in a special way
if gcd_options::no_part_factored flag is set.

GiNaC tries to avoid expanding expressions while computing GCDs and applies
a number of heuristics. Usually this improves performance, but in some cases
it doesn't. Allow user to switch off heuristics.

Part 4:

refactor gcd() a little bit, so subsequent patch(es) won't be so big and ugly.

GiNaC tries to avoid expanding expressions while computing GCDs and applies
a number of heuristics. Usually this improves performance, but in some cases
it doesn't. Allow user to switch off heuristics.

Part 3:

Move the code handling products from gcd() into a separate function. This
is *really* only code move, everything else should be considered a bug.

GiNaC tries to avoid expanding expressions while computing GCDs and applies
a number of heuristics. Usually this improves performance, but in some cases
it doesn't. Allow user to switch off heuristics.

Part 2:

Move the code handling powers from gcd() into a separate function. This
is *really* only code move, everything else should be considered a bug.

GiNaC tries to avoid expanding expressions while computing GCDs and applies
a number of heuristics. Usually this improves performance, but in some cases
it doesn't. Allow user to switch off heuristics.

Part 1:

* add new (optional) argument to gcd() to control its behaviour.
* introduce gcd_options structure.

N.B. No actual code changes so far, the actual handling of newly introduced
options is the subject of further patches.

1. Bad performance. Parsing a sum seems to be O(N^{2 + a}) (a > 0) [1].
For example, parsing a sum (actually, a univariate polynomial) of 32768
terms takes about 90 sec. on my box, parsing a sum of 10^6 terms takes
"eternity".
2. The user is expected to provide list of all symbols in the expression.
Often this is very annoying (and useless).
3. Parser is not reentrant (bison *can* produce reentrant parsers, but that
won't solve other problems).
4. Parser is difficult to extend.

1. Error handling is a bit terse: on error exception is thrown, and that's it.
2. Binary, octal, and hexadecimal numbers can not be parsed (yet).
3. Tensors, noncommutative products, etc. can not be parsed.

Other notes:

1. ex ctor still uses the old parser.
2. ginsh still uses the old parser.

A complex number can have an exact real part and inexact (floating point)
imaginary part, and vice a versa. Handle these cases properly in the archiving
code instead of bailing out with a bizzare error message.

Thanks to Chris Bouchard for reporting the bug.

NOTE: this fix changes the format of GiNaC archives, so formally it breaks
the binary compatibility. However, "mixed" complex numbers (i.e. ones with
exact real part and inexact imaginary part) can not be archived with previous
versions of GiNaC, so there's nothing to break.

inifcns_nstdsums.cpp: S_num takes cl_N as an argument instead of numeric.

Implicit conversion from cl_N to numeric considered harmful.

Using GiNaC::numeric for numerical computations incurs significant
overhead, so one might want to do these computations using proper CLN
types. Unfortunately, it's not easy due to automatic conversion from
cln::cl_N to GiNaC::numeric. Here is a simple example: