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