Hi, On Sun, 24 Aug 2003, Christian Bauer wrote:
On Sun, Aug 24, 2003 at 08:54:19PM +0200, Richard B. Kreckel wrote:
Log Message: - charpoly(): lambda is now a "const ex &" instead of a "const symbol &"
Is this a speed issue or something else?
I see no reason why lambda should be restricted to symbols. The implementation of the algorithm doesn't require it.
In this case, you're right. Leverrier's algorithm doesn't require it and determinants don't require it either. Okay. C'mon, that answer was trivial! I was just panicking over object fusion, but it seems that the doors to chaos and madness are rather closed in GiNaC 1.2: As part of the GiNaC evolution towards a modular bridge, some functions received an ex as argument instead of a symbol. Kompatibility will be maintained by ex representing symbols? On Sun, 24 Aug 2003, Christian Bauer wrote to ginac-cvs@ginac.de:
Modified Files: ex.h ex.cpp Log Message: - implemented object fusion as proposed by Richy - unit(), content() and primpart() take a "const ex &" instead of a "const symbol &". degree(), coeff(), collect() etc. have dropped the restriction to symbols a long time ago, so there's no reason for these function to keep it.
That may be somwhat dangerous, but in the end it's great news. What I would now like to research are the options to put a symbolic class derived from ex (withoug vtbl/vptr) at the interface side and thus complete the bridge pattern even more (following CLN's design). This would also completely avoid confusing code like this one: On Thu, 10 Jul 2003, Christian Bauer wrote to ginac-list@ginac.de:
because the symbol objects in the expression are heap-allocated copies of "a" and "b", but this works:
symbol &a_sym = *new symbol("a"); a_sym.setflag(status_flags::dynallocated); symbol &b_sym = *new symbol("b"); b_sym.setflag(status_flags::dynallocated); ex a = a_sym, b = b_sym;
I'll keep you posted. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@GiNaC.DE> <http://www.ginac.de/~kreckel/>