invalid expression in content|unit|...()

Pearu Peterson pearu at cens.ioc.ee
Thu Nov 22 19:10:56 CET 2001


On Thu, 22 Nov 2001, Richard B. Kreckel wrote:

> We had this layout already where constant was derived from symbol and we
> changed it because it turned out to produce all kinds of weird problems.  
> That seems to have been before 0.4.0, though, since I can't find it in the
> archives right now.  Generally it is considered problematic to have a
> concrete class for use by folks and derive another concrete class from it.
> Scott Meyers discusses this in his books to some extend.
> 
> >From a design perspective, I would much rather have an intermediate class
> derived from basic from wich both constant and numeric are derived.  This
> class could then provide everything these two have in common.

Ok then, but how about the following solution: remove constant
class altogether and put its current initnumber/efun stuff into symbol
class. Is there any reasons not to take this approach other than it
would be rather radical one (and broke some codes that use constants)?

Btw, there was one failure in checks caused by deriving constant from
symbol. Here are relevant messages:

examining indexed objects........ failed
simplify_indexed(p.i^2*q.j^2-p.n^2*q.j^2)-0 erroneously returned
p.i^2*q.j^2-q.i^2*p.j^2 instead of 0

Other tests passed fine.

Regards,
	Pearu





More information about the GiNaC-devel mailing list