I think simplification breaks your scope stuff.
integrate(sqrt(-1),%i) will see
all subexpressions simplified, hence it becomes integrate(%i,%i).
However that leftmost %i is the global imaginary unit, whereas the
rightmost %i
would be the different lexical %i. Hence the result would be %i*%i.
which is, of course different from %i^2 or -1 or.
Frankly, there seem to be several error treatments. anthropomorphizing a
bit ...
1. The program doesn't know how to proceed and doesn't even have a guess.
Perhaps a bug of its own.
2. The program has identified what is probably a user error
a. it can continue without warning
b. it can continue with warning
c. it can refuse to continue without revision
d. maybe something else.
3. The program refuses to try to identify any user error and
just plows ahead (typical of maxima) hoping that someone later
can make sense
On 7/30/13 10:02 AM, Robert Dodier 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