Re: [Maxima-discuss] subscripted functions

[Leo B. <l_b...@us...>]

Richard Fateman <fa...@be...> writes:

> I find the old behavior to be preferable. I suggest an alternative. 
> Here's why..
>
>   I think the array functions f{n](x):= ...  should be simplified with
> respect to each particular n and stored in that simple form.  That was
> clearly the intent, for example in defining orthogonal polynomials:
>
> compare
>
> p[0](x):=1$
> p[1](x):=x$
> p[n](x):= 1/n*( (2*n-1)*x*p[n-1](x)-(n-1)*p[n-2](x))$
> p[4];
>
> kill(p)$
> p[0](x):=1$
> p[1](x):=x$
> p[n](x):= ratsimp(1/n*( (2*n-1)*x*p[n-1](x)-(n-1)*p[n-2](x)))$
> p[4];
>     This p[4]  is WAY better.

Premature simplification produces this crap, too:

f[k](e) := coeff(e,x,k)$
f[2](3*x^2-1) --> 0.

It is pretty hard to justify that, imo.

In my experience, the headaches and obstacles caused by premature
simplification massively outweigh the putative benefits. In fact, the
behaviour is so counter-intuitive to users whom I have tutored that I
steer them away from the ugliness and encourage them to write functions
that return functions, i.e. re-implement parameterized functions.

> ..........
>
> Part of the effect that you are seeking can be obtained by writing  
> f(n,x)  instead of f[n](x).

Part, yes, but not the whole and that is the problem. In many cases, one
wants a function parameterized by a number of values, i.e. one wants and
expects f[n] to be the function equivalent to lambda([x],f(n,x)). The
current policy means they are not. The patch allows one to choose.

>
> I think that the rest of the effect you are seeking is equivalent to 
> allowing "Currying".  In particular, any time a (trailing)
> argument is left off, it is not an error, but an opportunity for created 
> another function.
>
> f(x,y,z):=x+y+z$
> f(x,y);    now produces an error message about "too few arguments".
>
> Maxima could be changed so that
> f(a,b) becomes    lambda([z], a+b+z).
> f(a) becomes lambda([y,z], a+y+z).

I am not trying to nitpick, but shouldn't it be

f(a,b) --> lambda([z],f(a,b,z))

etc.

>
> So here's a proposal that should not break any existing correct programs 
> at all.
> (Unless there is a program that DEPENDS on the error "too few arguments 
> ....)
>
> Allow currying.
>
> Comments?

As a mathematician, I like the idea of currying. But, I think that it
will create a huge headache if implemented as you suggest. How does one
curry the function

f([x]) := x$

?

Leo


>
> RJF
>
>
> On 4/2/2014 9:38 AM, Leo Butler wrote:
>> Robert Dodier <rob...@gm...> writes:
>>
>>> On 2014-03-11, Leo Butler <l_b...@us...> wrote:
>>>
>>>> As a counterpoint, the behaviour is documented and has been a part of
>>>> Maxima/Macsyma for ~20 years at least. I don't know who would be
>>>> counting on the behaviour, though, as opposed to working around
>>>> it. But maybe that is my limited imagination.
>>> I dunno. Maxima's idiosyncrasies are a dime a dozen and if we are to
>>> make any progress, we can't sustain them all indefinitely. I don't
>>> consider the weight of history enough to prevent us from changing
>>> anything.
>> I am attaching a patch to change how subscripted function definition
>> works. The current behaviour, although clumsy and confusing, can be
>> recovered by means of a switch. I would like to remove the old behaviour
>> in the future, but I prefer to have a transition period.
>>
>> Here is a sample of the change, from tests in rtest1.mac:
>>
>> By default, the old behaviour is off:
>>
>> (%i1) array_fun_eval_inner_form;
>> (%o1) false
>>
>>
>> (%i2) g[n](x):=sum(x,i,n,n+2)$
>>
>> (%i3) g[2](i^2);
>> (%o3) 29                <-- 2^2 + 3^2 + 4^2
>>
>> (%i4) p[n](x):=ratsimp(1/(2^n*n!)*diff((x^2-1)^n,x,n))$
>>
>> (%i5) p[5];
>> (%o5) lambda([x],block([n:5],ratsimp(1/(2^n*n!)*diff((x^2-1)^n,x,n))))
>>
>> (%i6) p[5](y);
>> (%o6) (63*y^5-70*y^3+15*y)/8
>>
>>
>>
>> By contrast, the old behaviour can be recovered:
>>
>> (%i7) remarray(all)$
>>
>> (%i8) array_fun_eval_inner_form:true $
>>
>>
>> (%i9) g[n](x):=sum(x,i,n,n+2)$
>>
>> (%i10) g[2](i^2);
>> (%o10) 3*i^2          <-- note the difference with %o3
>>
>>
>> (%i11) p[n](x):=ratsimp(1/(2^n*n!)*diff((x^2-1)^n,x,n))$
>>
>> (%i12) p[5];
>> (%o12) lambda([x],(63*x^5-70*x^3+15*x)/8)  <-- note difference with %o5
>>
>> The following would throw an error with the new behaviour, but because
>> the legacy behaviour is to evaluate the RHS of %i11 with n equal to 5,
>> then plunk the result into a lambda function (as in %o12), it is fine:
>>
>> (%i13) p[5](y+1);
>> (%o13) (63*(y+1)^5-70*(y+1)^3+15*(y+1))/8
>>
>> I have added/modified the testsuite (rtest1.mac and rexamples.mac), and
>> all other tests run as expected with the new default behaviour.
>>
>> Comments?
>>
>>
>
>
> ------------------------------------------------------------------------------

-- 
Leo Butler                <l_b...@us...>
SDF Public Access UNIX System -   http://sdf.lonestar.org