On 4/8/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> > How about if we generalize makelist to take multiple indices
> > and cut create_list entirely.
>
> I agree that we should generalize makelist. But if we allow it to
> take BOTH multiple indices and a range defined by i,lowval,highval we
> run into the ambiguity I mentioned in my previous mail.
To be clear, I want makelist to recognize arguments like this:
makelist (expr, i, i0, i1, j, j0, j1, k, k0, k1, ...)
where i, j, k, ... are symbols and i0, i1, j0, j1, k0, k1, ... are integers.
makelist also recognizes makelist(expr, x, L) where L is a list.
I guess I would suggest cutting that. Allowing that and also the
notation with integers leads to ambiguity as noted before.
map(lambda([x], expr), L) has the same effect (ignoring
evaluation subtleties) as makelist(expr, x, L) so we don't really
need the latter, and map already allows multiple arguments too.
> Something that would allow both in a much cleaner way would be some
> sort of notation for an integer sequence, e.g. a .. b, so that you
> could have
>
> makelist( i*j, i, 1 .. 3, j, 3 .. 4)
>
> Then there wouldn't be this disaster of the interpretation of the
> arguments depending on their value. The simple way to implement this
> would be to have a..b expand to [a, a+1, ... , b]. A more
> sophisticated implementation (but which would require a lot more work
> to do fully) would have ".." remain unexpanded.
I like the idea of recognizing ellipsis notation but I wouldn't
bother changing makelist if it were available. That said, it
would be useful in other places so I am in favor of pursuing it.
I've never liked the notation .. for an ellipsis.
Why not type 3 dots and have a proper ellipsis.
Typing .. instead of ... is one of those unhelpful abbrvtions.
> The main hesitation I have about using ".." in this way is that it
> covers one rather special case, not including other step sizes etc.
> It gets complicated to have (2..5)/3 represent [ 2/3, 1, 4/3, 5/3]
> without expanding it, because there are lots of other cases, e.g.
> reverse(2..5), concat(2..5, 3..7), etc., none of which are currently
> simplifying functions.
Non-integer step sizes are problematic anyway, because we
would need to enforce some rule about what to do when
(end - beginning) is not an integer number of steps.
An expression like ((m ... n) * step + x0) is unambiguous.
So if Maxima allows only 1 as the step, that's OK by me.
Making reverse, append, etc into simplifying functions makes
sense to me. It would be some work but I think it's well
within reach.
FWIW
Robert