GiNaC/ginac matrix.cpp matrix.h

[Richard B. Kreckel]

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 at 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 at 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 at GiNaC.DE>
<http://www.ginac.de/~kreckel/>