On Sun, Nov 25, 2012 at 11:19 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
> On 2012-11-25, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>
> > It seems to me that there is no good reason to be defining simplification
> > rules on verbs. Yes, I can construct scenarios where it would be useful
> > (see below), but even if someone does that someday, I'd argue it is a
> very
> > very specialized and unusual case. The usual case is application of
> > tellsimp rules during general simplification of whole expressions, in
> which
> > there should be no verbs at all (remember that simplification doesn't
> reach
> > inside lambdas including function definitions).
>
> A useful way (widely used within Maxima) to implement an operator is as
> a function which has simplification rules but no function definition.
> For these functions, there is no useful distinction between nouns and
> verbs, and typically only the verb form is ever used. Surely it should
> be possible to define rules for such functions.
>
Completely agree. I think what you're really pointing out here is an
inconsistency in Maxima's treatment of "intrinsic" functions and other
functions; a user function f with no definition should surely be considered
a noun form. But you're right that my proposal as stated fails badly here.
Rewriting expressions, as in the code generation example you cited, is
> perhaps specialized, but surely not beyond the scope of symbolic
> computation -- I think it is needlessly limiting to rule out such
> operations.
>
I agree that it is potentially interesting and useful. In fact, I worked
on things like that many years ago. I just find it unfortunate that in the
common, existing cases of diff, limit, integrate, laplace, etc. the user
needs to think about the noun/verb business.
> So I would suggest that tellsimpafter(f(...),...) should be interpreted as
> > applying to the *noun* f.
>
> I dunno -- irregular behavior in the interest of convenience (guessing
> what the user wants) generally makes it harder to predict what is the
> effect of some operation. I wouldn't want to make it harder to
> understand simplification rules ....
>
You're right, as stated, my proposal fails. But there should be some way
to simplify things....
-s