The implementation of makelist should no doubt be rethought.
However, using create_list instead of makelist would be a very bad idea,
because create_list has a fatal flaw in its semantics (not its
implementation). See my email below. Create_list should be redesigned to
avoid this flaw.
-s
On Sun, Oct 12, 2008 at 8:22 PM, John Lapeyre <pdl at johnlapeyre.com> wrote:
> On Sunday 12 October 2008 01:00:46 pm Stavros Macrakis wrote:
>
> > >... makelist should probably be rewritten
> > It sounds like that would be a good idea.
>
> ... makelist appears to be older than create_list. But I suspect
> create_list
> would work as a drop in replacement for the majority of the cases in
> share....
---------- Forwarded message ----------
From: Stavros Macrakis <macrakis at alum.mit.edu>
Date: Sat, Apr 7, 2007 at 9:49 AM
Subject: Re: [Maxima] makelist vs create_list
To: Kostas Oikonomou <ko at research.att.com>
Cc: Maxima <maxima at math.utexas.edu>
On 4/6/07, Kostas Oikonomou <ko at research.att.com> wrote:
> ...I'm wondering why Maxima has both makelist() and create_list().
>
Bad design. Of course there shouldn't be two redundant functions like this.
There is also a serious problem with the design of create_list. Its
generalization to multiple variables is very useful and unproblematic.
On the other hand, the fact that it allows either lists or ranges
defined by integers makes its semantics weird, with the interpretation
of its arguments depending on their values. Consider:
(a:1,b:2,c:3,d:4)$
create_list(i*j, i, a, b, j, c, d) => [3,4,6,8]
vs.
(a:[1,2],j:[3,4],d:[5,6])
create_list(i*j, i, a, b, j, c, d) =>
[[3, 4], [3, 4], [3, 4], [3, 4], [6, 8], [6, 8], [6, 8], [6, 8]]
This is disastrously poor design. With identical syntax, in the first
case, i and j are treated as variable names; in the second case, i, b,
and c, are considered as variable names. We should remove the "range
defined by integers" case from create_list.
-s