Maxima/Ecl on 32-bit machine cannot evaluate "apply(union, listify({{..}}))"

Hi,

some report on the investigations into this bug:

1) I did run

for N step 10 thru 5000 do (print(N), apply(union, create_list({},i,1,N)));

on all machines (32 / 64 bits), with ECL (5.16.3) and CLisp (5.15.0, 5.16.3),
and none showed any problems.

This would have surprised me anyway, since set-operations are the bread-and-butter
of my library, and I'm typically performing much larger unions, intersections etc.
(in Maxima).

Remark: One should deprecate "makelist", since
 - create_list is much more powerful
 - makelist has a bug when the loop is empty
 - create_list is quite a bit faster when it comes to big
   lists (while not being slower for small lists).

I typically miss such guidance in Maxima: This is not the only case
where one function is clearly superior over another function, but
there is no hint at all even at the co-existence.

2) trace(union) yields

1" Enter "union" "[{-6,-5,-4,-3,-2,-1},{-6,-5,-4,-3,-2,1},{-6,-5,-4,-3,-1,2},{-6,-5,-4,-3,1,2},{-6,-5,-4,-2,-1,3},
 {-6,-5,-4,-2,1,3},{-6,-5,-4,-1,2,3},{-6,-5,-4,1,2,3},{-6,-5,-3,-2,-1,4},{-6,-5,-3,-2,1,4},
 {-6,-5,-3,-1,2,4},{-6,-5,-3,1,2,4},{-6,-5,-2,-1,3,4},{-6,-5,-2,1,3,4},{-6,-5,-1,2,3,4},
 {-6,-5,1,2,3,4},{-6,-4,-3,-2,-1,5},{-6,-4,-3,-2,1,5},{-6,-4,-3,-1,2,5},{-6,-4,-3,1,2,5},
 {-6,-4,-2,-1,3,5},{-6,-4,-2,1,3,5},{-6,-4,-1,2,3,5},{-6,-4,1,2,3,5},{-6,-3,-2,-1,4,5},
 {-6,-3,-2,1,4,5},{-6,-3,-1,2,4,5},{-6,-3,1,2,4,5},{-6,-2,-1,3,4,5},{-6,-2,1,3,4,5},
 {-6,-1,2,3,4,5},{-6,1,2,3,4,5},{-5,-4,-3,-2,-1,6},{-5,-4,-3,-2,1,6},{-5,-4,-3,-1,2,6},
 {-5,-4,-3,1,2,6},{-5,-4,-2,-1,3,6},{-5,-4,-2,1,3,6},{-5,-4,-1,2,3,6},{-5,-4,1,2,3,6},
 {-5,-3,-2,-1,4,6},{-5,-3,-2,1,4,6},{-5,-3,-1,2,4,6},{-5,-3,1,2,4,6},{-5,-2,-1,3,4,6},
 {-5,-2,1,3,4,6},{-5,-1,2,3,4,6},{-5,1,2,3,4,6},{-4,-3,-2,-1,5,6},{-4,-3,-2,1,5,6},
 {-4,-3,-1,2,5,6},{-4,-3,1,2,5,6},{-4,-2,-1,3,5,6},{-4,-2,1,3,5,6},{-4,-1,2,3,5,6},{-4,1,2,3,5,6},
 {-3,-2,-1,4,5,6},{-3,-2,1,4,5,6},{-3,-1,2,4,5,6},{-3,1,2,4,5,6},{-2,-1,3,4,5,6},{-2,1,3,4,5,6},
 {-1,2,3,4,5,6},?\#\<illegal\ pointer\ bfff0e28\>]""""
Function union expects a set, instead found ?the\-trace\-apply\-hack
 -- an error.  To debug this try debugmode(true);

3)  trace(listify,apply) additionally just yields

 1" Enter "union" "
Maxima encountered a Lisp error:

 #<frame 268451060 3221163056> is not of type SI:INSTANCE.

4) load(nset) actually makes the error disappear.

I don't understand fully what this does, but I guess the standard-definitions
are just reloaded, and thus not compiled?

Just a remark: Also under CLisp "compile" seems to be completely useless on my
own functions:
Spits out a lot of warnings (much regarding Maxima-code), and then the system
outputs only rubbish in the sequel.

------------------

A possibility would be to run Maxima/ECL only with "load(nset)", which costs
~ 25% runtime, but ECL still is faster then than CLisp.

Unfortunately, there is another bug (apparently independent of the load(nset)-issue,
which seems to kill Maxima/ECL (at least for now).

I'll start another thread for that.

Oliver


On Mon, Sep 01, 2008 at 08:16:54AM -0600, Robert Dodier wrote:
> On 9/1/08, Oliver Kullmann <O.Kullmann at swansea.ac.uk> wrote:
> 
> >  Function union expects a set, instead found union
> >   -- an error.  To debug this try debugmode(true);
> 
> Hmm. What does trace(union) show as the arguments to union ?
> If there is some expression in the arguments which is union(...) instead
> of {...}, maybe trace(listify, apply) shows from where it originates.
> 
> Does load(nset) make the problem go away? (By running interpreted code
> instead of compiled.)
> 
> I'm guessing this is an ECL bug, but I don't know how to figure out what it is.
> 
> HTH
> 
> Robert Dodier