Make add::eval(), mul::eval() work without compromise.
authorRichard Kreckel <kreckel@ginac.de>
Wed, 16 Dec 2015 12:00:30 +0000 (13:00 +0100)
committerRichard Kreckel <kreckel@ginac.de>
Wed, 16 Dec 2015 12:00:30 +0000 (13:00 +0100)
commitae6c004bd31e02dda37357d74b641c101b116c73
tree317542e2a8bfeb75b52b3eeb655d56d69b6d294d
parent65f2693a0948d1db0bc68d7656c64e1fed91c158
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...)
check/exam_paranoia.cpp
ginac/add.cpp
ginac/expairseq.cpp
ginac/function.cppy
ginac/mul.cpp
ginac/normal.cpp
ginac/power.cpp