[GiNaC-devel] Custom power evaluation

Sheplyakov Alexei varg at theor.jinr.ru
Mon Oct 30 17:29:17 CET 2006


Hello,

On Sat, Oct 28, 2006 at 08:57:27PM +0100, kisilv at maths.leeds.ac.uk wrote:
> > My concerns are rather that rooting something as specialized
> > inside the class hierarchy will not be useful enough but open the
> > floodgates for much more specialized ideas and make the code even harder
> > to understand for novices.
> 
> Once more: nothing specialised is intended for the GiNaC core classes.
> This is only a pair of wires leading outside of the kernel where an end
> user can connect his own devices to.

What if someone else wants to insert another "pair of wires" to
implement another weird feature? And than one more... making the whole
thing more cumbersome and slow (yes, two extra useless method calls do
not really improve the performance). Please stop adding more methods to
core classes (unless there is a _really_ good reason for this), there
are already much of them (evalm, evalf, eval_integ, eval_indexed, 
eval_ncmul). Pretty please.

> > Have you tried using subs or custom tree traversers for your purpose?
> > (Along the ideas sketched in the FAQ, I mean.)
> 
> Imagine that any calculation with complex numbers will require manual
> substitution of I^2=-1, will it be convenient?

It depends. E.g., for someone who hardly ever uses complex numbers this
is not a big deal. On the other hand,

> +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}.

This sounds like modular arithmetics (in Z_3, to be more specific).
It would be nice if GiNaC had support of such a thing. CLN has modular
integers, so _probably_ it is possible to do such calculations in
more natural way (so that simplification of this kind are handled by
CLN, just as I^2 -> -1).

> The purpose of the extension is just to let a user a freedom to make 
> some such simple rules work automatically. 

IMHO, GiNaC's purpose is somewhat inverse: not to give as much freedom
as possible, but to restrict the freedom to do some specific things
effectively.  BTW, other tools used by [particle] physicists (e.g. FORM)
are even more restrictive, and there are very few complaints (if any)
about that.

> It is the responsibility of the end user to decide himself what kind 
> of rules are suitable for his task.

The main point is not validity of those rules. Your implementation
complicates things even for those who are not going to use any of
such rules.
 
> I think that this is a nice way to keep GiNaC kernel small and tidy
> and yet suitable for very wide set of questions.

IMHO, this is exaclty the way to make it more cumbersome without any
positive side effects.


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/20061030/d78070a4/attachment.pgp


More information about the GiNaC-devel mailing list