[GiNaC-devel] Custom power evaluation
Sheplyakov Alexei
varg at theor.jinr.ru
Fri Oct 27 18:00:53 CEST 2006
Hello,
On Fri, Oct 27, 2006 at 12:37:03PM +0100, Vladimir Kisil wrote:
> Following my previous message on the subject
> (http://www.ginac.de/pipermail/ginac-devel/2006-October/001071.html) I
> am including the full patch. Its functionality is now described in
> ginac.info.
[snipped]
While I certainly like the idea, I dislike the proposed implementation
very much. Keep on reading to find out why.
> +It is not unusual to use some objects which have special properties with
> +respect to exponentiation. For example, if a symbol @code{s} may take
> +only values @math{-1} or @math{1} then @math{s^2=1}. Other examples are
[snipped]
GiNaC offers ex::map() method for implementation of such custom
evaluation rules. Frankly, I don't understand why it is not enough...
> + at example
> + virtual ex basic::eval_power_basis(const ex & exp) const;
> + virtual ex basic::eval_power_exponent(const ex & basis) const;
> + at end example
Adding more methods to the `basic' class does not sound like good
idea to me. What if someone implements custom evaluation rules, say,
for the `mul' class? E.g. foosymbol times barfunction is always zero.
Add even more methods to basic?
[snip]
> + at example
> + your_class::info(info_flags::is_power_basis);
> + your_class::info(info_flags::is_power_exponent);
> + at end example
Likewise, I think adding even more stuff to info_flags is bad idea.
[huge snip]
> +ex basic::eval_power_basis(const ex & exp) const
> +{
> + std::cerr << "WARNING: virtual method basic::eval_power_basis is called," << std::endl
> + << " did you forget to redefine it in the derived class?" << std::endl;
> + return power(*this, exp).hold();
> +}
Spamming to std{out,err} is a MORTAL SIN. NEVER, EVER do this.
Either return the expression unevaluated or throw an exception.
> + // user defined classes may provide their own virtual methods for power evaluation
> + if (ebasis.info(info_flags::is_power_basis))
> + return ebasis.eval_power_basis(eexponent);
> +
> + if (eexponent.info(info_flags::is_power_exponent))
> + return eexponent.eval_power_exponent(ebasis);
This slows down a bit evaluation of *every* power expression, including
those which do not provide such a method. GiNaC's performance is not
exactly brilliant, why reduce it even more?
Best regards,
Alexei
--
All science is either physics or stamp collecting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20061027/afc14e97/attachment.pgp
More information about the GiNaC-devel
mailing list