[Maxima] New function - makelist alternative: table()

Žiga Lenarčič ziga.lenarcic at gmail.com
Sun May 10 14:43:42 CDT 2009

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

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

More information about the Maxima mailing list