Subject: New function - makelist alternative: table()
From: Žiga Lenarčič
Date: Sun, 10 May 2009 21:43:42 +0200
Hi Starvos!
> The only incompatibilities I've found so far with makelist are:
>
> makelist(i,i,a,a+2) => [a, a+1, a+2]
> table(i, [i,a,a+2]) => error
> table(i, [i,%i,%i+2]) => similarly, error
> makelist(a[i],[a[i],2,3]) => [2,3]
> table => error
>
> Some corner cases where I'm not sure what the ideal behavior is:
>
> table(i,[i,2,3],[i,6,7]) => [[2,2],[3,3]] (give an error?)
Mathematica here gives
[[6,7],[6,7]] with no error (but mathematica often rather produces
strange results than give errors - perhaps to make it look more
'correct'). My table 'conses' value bindings, that's why it uses the
first one rather than the second (the order of binding is reversed,
which matters when you bind to same variable).
I really don't know what is best in this situation. Error checking is
possible (member?) I think.
> table( j, [i, 1, 3], [j, 1, i ]) => error (exchanging i/j gives
> the same error)
This last one is fixed now.. (see attachment). Iterators need to be
evaluated with previous iterator's binds.
I would very much like to expand table() to work on these more
general cases. However my knowledge of Maxima internals is somewhat
lacking.
Right now the most general case, $table can work with is for instance
table(i, [i, 0,10,1/2]);
In this case iterator's begin, end and step are checked with $numberp
for validity and 'mgrp' and 'mlsp' for ending iteration. $table works
this way, that if iterator is made of 'lisp' numbers it calls a
faster function than if iterator includes 'maxima' numbers...
Iteration can be extended easily while perserving the speed of the
usual case ('lisp' numbers) - only proper checks are needed for
stopping iteration and preventing errors. The core of iteration is
alyways the same - binding values to maxima variables in a recursive
way if there are more iterators than one. (but you probably know that
if you inspected source code).
I need advice: How should I check iterator contents (if it's valid)
to include these more general cases, but maybe prevent some errors?
Right now $table is robust - you can't force it to do an endless
iteration without error. With more general expressions allowed in
iterators, there is a danger of endless iteration... I personally
don't mind that..
What functions should be used for '<' '>' comparison of maxima
complex numbers? Any hints on implementing the cases above?
> makelist(i,i,1,0) => [] ... it is useful for the empty case
> to be specifiable this way
> table(i,[i,1,0]) => error
This is debatable - give an error or produce a result (like
mathematica). I decided for errors when was writing, but both are
easy to do. Error can prevent a user to do something, he/she actually
doesn't want to do (the way I see it, user in this situation probably
made a mistake). But [] is somehow correct too and can extend
functions 'generality'. I'm in favour of an empty list [].
> A case that works correctly in your code but is not documented in the
> opening comment is [var, list]. I'd think that this should work for
> sets, too. The error message also needs to be corrected from "... is
> not a number" to "... is not a number, list, or set".
Agreed. I should use $setp to check if it is a set if I understand
correctly.
Regards,
Ziga Lenarcic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table.lisp
Type: application/octet-stream
Size: 11495 bytes
Desc: not available
Url : http://www.math.utexas.edu/pipermail/maxima/attachments/20090510/ea67e2f0/attachment-0001.obj
-------------- next part --------------