improvement (hopefully) to subs and a patch included
chrisd at catv7250.extern.kun.nl
chrisd at catv7250.extern.kun.nl
Wed Nov 27 20:42:15 CET 2002
Hello,
On Wed, 27 Nov 2002, Christian Bauer wrote:
> On Mon, Nov 18, 2002 at 12:11:28PM +0000, Chris Dams wrote:
> > Here is a patch that is supposed to make substitutions, optionally, a bit
> > more semantic (as opposed to syntactic).
>
> This looks interesting. Any particular reason why sums aren't treated in
> a "smart" (should we call that "algebraic") way?
In my experience it is quite often so that the most useful form to
manipulate expressions in, is the expanded form. When using this form most
things can be achieved by only using "smart" (or "algebraic")
substitutions on multiplications. For instance, the
cos^2(whatever)+sin^2(whatever)==1 example in the FAQ, becomes
cos^2(wild())==1-sin^2(wild()) and after expanding again, one gets a more
or less canonical form for a polynomial of sin's an cos'es that only has
cos to the power 0 or 1. Generally, I think the primary use of the smart
substitutions (I have no objections if you call them "algebraic") is to
canoncialize expressions in the users favourite expression domain to the
users favourite canonical form. For this one quite often only needs
smart/algebraic substitions for multiplications and no smartness for
additions. Furthermore, smart substitution in additions is a bit of a
difficult subject if one has expanded expressions in mind.
> > The subs method gets an extra optional argument like this
> >
> > ex subs(const lst & ls, const lst & lr, unsigned options = 0, bool no_pattern = false) const
>
> The 'no_pattern' could be moved to 'options' (something like
> 'subs_options::no_pattern').
Does sound like a good idea. Hadn't yet thought about that.
> > cout << (4*x*x*x-2*x*x+5*x-1).subs(pow(x,wild())==pow(a,wild()),
> > subs_options::subs_smart) << endl;
> > // --> -1+5*x+4*x^3-2*x^2
>
> Not "-1+5*a+4*a^3-2*a^2"? (I haven't tried the patch yet...)
Have thought about it, but then I came to the conclusion that the way
things go now, this would preferably be based on smartness (or
algebraicness) in the .match() method (and is not terribly convenient to
realize in a way that users would think of as being consistent without
that). The problem is that pow(x,wild()) does not match x, which is used
internally to find the number of times a pattern matches. I prefered
smarting (or algebraicing) one method at the time (be it only for keeping
the size of my patches moderate) and perhaps the time for smarting
.match() will never come because my guess would be that the kind of
pattern in which the exponent is a wildcard is not of terribly much use in
most cases if smart substitution is available.
Bye,
Chris Dams
More information about the GiNaC-devel
mailing list