[GiNaC-list] Bug with evalm()?

[Richard B. Kreckel]

Hi!

Sheplyakov Alexei wrote:
>>Because it is certainly non standard, that you construct an instance
>>of some class Add(x,x) and it returns an instance of a completely
>>different class Mul(2,x).
> 
> 
> This is certainly impossible in C++. But the question is: may be
> "virtual constructors" are not necessary at all? Suppose there is 
> the Polynomial<Ring> type, and 
> 
> Polynomial<Ring3> operator+(const Polynomial<Ring2>&, const
> Polynomial<Ring1>&);
> Polynomial<Ring3> operator*(const Polynomial<Ring2>&, const
> Polynomial<Ring1>&);
> Polynomial<Ring3> operator*(const Polynomial<Ring2>&, const Ring1&);
> etc.

I suppose you meant Ring1 == Ring2 == Ring3.

> Thus the return types are known at the compile time: if x is polynomial,
> then x + x is polynomial too. Thus there is no need for "virtual 
> constructors". And compiler can catch more mistakes:
> 
> Polynomial<Z> A = x; // OK
> Polynomial<Z> B = x + 0.5; //  ERROR

Right, but all this is not too helpful when there is no way of knowing 
at compile time what the ring is. After all, modular rings are different 
types if they have different moduli and knowing the modulus at compile 
time is not always possible. Think of public-key crypto algorithms where 
moduli have typically around 1000 bits and are determined dynamically by 
RNGs followed by a probabilistic primality test.

Did you know that CLN's cl_univpoly_ring class is doing more or less 
what you suggest? It is delegating consistency checks like the above to 
runtime, however. And it is somwehat too complicated, in my opinion.

Alas, there is no way out of this: Parametric types in C++ are 
determined at compile time. Just like all types in C++.

Best
   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>