[GiNaC-devel] Custom power evaluation

[Sheplyakov Alexei]

Hello,

On Fri, Oct 27, 2006 at 05:17:23PM +0100, Vladimir Kisil wrote:
>     SA> GiNaC offers ex::map() method for implementation of such custom
>     SA> evaluation rules. 
> 
> 	Unfortunately I cannot see how to use map() for simplification of
>   automatic evaluations for derived classes, could you give me a hint?

I'm sorry, I didn't realize that the the whole thing is about *automatic*
evaluation. Now I have even more objections against your patch, in
particular, I'm concerned about the idea itself (not only about the
implementation). In general, automatic evaluation rules are quite minimalistic
by design. There are evalm(), evalf(), eval_integ(), simplify_indexed(),
etc. for more time-consuming simplifications. These must be called 
explicitly for a good reason. What about adding something like eval_pow()
which has to be *explicitly called* and does whatever evaluations you want?

>     SA> Adding more methods to the `basic' class does not sound like
>     SA> good idea to me.  What if someone implements custom evaluation
>     SA> rules, say, for the `mul' class? E.g. foosymbol times
>     SA> barfunction is always zero.  Add even more methods to basic?
 
> 	There is a limited number of evaluations (add(), mul(), ncmul()) so
>   only three additional virtual methods will cover any desire in
>   automatic evaluation.

To slow down things even more? I certainly dislike this. Once again,
adding some virtual method which does arbitrary time-consuming 
simplification *AND* never gets called automatically is not that bad
(in the sense "The things I don't use should not harm me").

>     SA> Likewise, I think adding even more stuff to info_flags is bad
>     SA> idea.
> 
>	However this makes a check for existence of an additional evaluation
> method much  quicker. Are there a better way to check this?
First of all, I don't understand why do you need such a check in first
place. Maybe, a better approach would be to provide sensible default
implementation (which does not change anything if there are no custom
rules) and call the method unconditionally?
 
>     SA> This slows down a bit evaluation of *every* power expression,
>     SA> including those which do not provide such a method. GiNaC's
>     SA> performance is not exactly brilliant, why reduce it even more?
> 
> 	However it make much-much more faster evaluation of expressions
>   which do contain such object.

If you do some optimizations for *very* special case, could you please
be so kind to not harm the generic one? The change to power::eval()
you've introduced costs at least two extra virtual method calls 
(I assume the general case when there are no any custom power evaluation
rules). Now evaluation of moderately sized multivariate polynomial (say,
10 variables, several million terms) consumes several million useless
instructions, even if eval() is going to just hold() the polynomial in 
question.

> For example, calculations in two
>   dimensions can be done now without usage Clifford algebras and *very*
>   time-expensive non-commutativity. 

> In my opinion it is a fair exchange for slowing down *a bit* for
> other calls. Everything in this world come at a price.

Since efficient handling of large polynomials is essential for GiNaC
(and probably for any other software for analytical computations) I 
don't think the price is acceptable.

Don't get me wrong -- I completely realize that GiNaC may have 
suboptimal performance for problems which are important for you.
But I don't think it is good idea to include your optimizations if
they harm everyone else. 

I've got a lot of small hacks which tune GiNaC for my problems too.
I post more or less generic of these (mostly bug fixes) here. For
example, some gcd() misfeatures (expanding partially factored expressions
for no good reason) were really show stoppers for me. Another example
is divide() and collect_common_factors() (see patches I've posted about
two weeks ago) misfeatures. These are very annoying too and make
my calculations virtually impossible. I'd like these patches to be
included in GiNaC, but if they won't get applied -- nothing prevents
me from patching GiNaC myself in whatever way I need to.

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061028/49ad22f8/attachment.sig>