constants. was Re: cobyla



Robert, all that is very interesting, but:

1) What does it do for the naive user, the one who simply doesn't know that
%i, %pi, etc. have special meanings?

2) What does that do to the extremely common and very useful pattern of
(val: <expression involving x>, ..., operation(val, x) )?  In this
expression, <expression involving x> is not within the scope of operation's
x.

3) If a %pi leaks, how do we distinguish it from other %pi's?

4) Binding constant symbols seems to be a small detail in your grand
scheme.  Let's figure out how to handle x and y first, then we can worry
about %i and %pi.





On Tue, Jul 30, 2013 at 1:02 PM, Robert Dodier <robert.dodier at gmail.com>wrote:

> On 2013-07-30, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
>
> > Now, there is a *principled* way of handling all this.  In the
> > *principled *approach,
> > we don't integrate/ antidifferentiate expressions, but functions, e.g.
> the
> > function lambda([%i],sqrt(-1)), and variables are really lexical, so we
> can
> > freely rewrite this <textually> as lambda([anyvariable345], sqrt(-1)).
> The
> > result is not an expression, but the function
> > lambda([anyvariable345],sqrt(-1)*anyvariable345).
>
> Yes, that is precisely what I'm thinking about.
>
> > But what is the shorthand for the result?  Can we sweep the functional
> > nature under the rug?
>
> Good question -- more about this below.
>
> > They also seem to like things like ''(xxx) and expr:<this and
> > so>; integrate(expr,x); where <this and so> is not explicitly a function,
> > and is not in a lexical environment where 'x' is defined as a function
> > argument.
>
> At this point I am inclined to impose implicit lexical environments only
> on those functions which seem to need them (integrate, sum, diff, etc).
> I do understand that "seem to need them" is kind of wobbly; how would a
> user know whether to expect lexical interpretation? I'll stagger forward
> regardless.
>
> > One of the advantages of Maxima over more formal systems is that we don't
> > force the user to over-formalize and to think about subtle stuff like
> this.
>
> Well, we developers will do the subtle thinking on their behalf, right?
>
> Perhaps a workable trade-off is to devise a lexical environment which
> indicates that the variables within are not the ones by the same names
> without, so if the user runs into a name collision, at least it is easy
> to work around it. Perhaps (perhaps) something like this:
>
>   integrate (%pi^2, %pi);
>    => oops: sorry brother, %pi's a constant
>
>   lexical_block ([%pi], integrate (%pi^2, %pi));
>    => 1/3*%pi^3
>
> Note that lexical_blocks can leak lexical symbols (as it does here) --
> I know the Lisp/Scheme crowd has worried about that, but I don't
> remember what's answer they arrived at. I would expect, at least, that
> the %pi leaking out of lexical_block is not the same as the global %pi.
>
> I think I posted an implementation of a lexical block some time ago --
> I think I called it 'blex'.
>
> About implicitly interpreting integrate, diff, etc in a lexical
> environment, some functions (integrate, sum, plot2d, maybe others)
> can't leak variables, so implicitly rewriting integrate(expr, x) to
> lexical_block([x], integrate(expr, x)) seems safe in the sense that
> the user can't later encounter a wandering x which is different from
> every other x. But diff is different; it usually leaks a variable.
> Implicitly rewriting diff(x^2, x) to lexical_block([x], diff(x^2, x))
>  => 2*x where x is distinct from all similarly-named symbols seems
> likely to lead to confusion. Not sure what to do there.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>