Re: [Maxima-discuss] subscripted functions

[Richard F. <fa...@be...>]

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.
..........

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

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).

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?

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?
>
>