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

On Tue, Sep 2, 2008 at 2:03 PM, Oliver Kullmann <O.Kullmann at swansea.ac.uk>wrote:

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

Interesting.  Maxima 5.15.0/GCL fails at 71.  Another interesting fact: it
fails differently if you use the interpretive version of nset, presumably
because it is using a different function call mechanism.


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

I'd still recommend you use xreduce rather than apply....  Are you sure your
results are correct?  Can you share code with us which performs much larger
unions and intersections?


> Remark: One should deprecate "makelist", since
>  - create_list is much more powerful
>

create_list has a design flaw in the multi-index case; see the discussion
archive under "[Maxima] makelist vs create_list" from 4/6/07


>  - makelist has a bug when the loop is empty


What is this bug (has it been reported?)?  Can't it be fixed?  Or is it a
design flaw?  As far as I can tell, makelist(print(i),i,0,-1) and
makelist(print(i),i,[])


>   - create_list is quite a bit faster when it comes to big
>   lists (while not being slower for small lists).
>

Let's get the semantics right first, then we can figure out efficient
implementations.


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

Though I don't agree that in this case "one function is clearly superior to
the other", I do agree that this sort of cross-reference is lacking in our
documentation.

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

Curious that argument #64 is garbage. This looks like a function-calling
problem.  And the fact that the interpretive version doesn't have the
problem reinforces that diagnosis.


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

This probably loads the interpretive version, which in many Lisp
implementations handles function calling slightly differently, notably not
having the same limitations on number of arguments. Perhaps CLisp does not
handle >63 arguments correctly, but doesn't trigger an error, but instead
continues computing with rubbish?


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

Sorry, I don't know anything about CLisp, but if there is a bug, please
report it in such a way that others can reproduce it.


> A possibility would be to run Maxima/ECL only with "load(nset)"


That is a reasonable workaround, apparently, but there is still a bug to be
fixed.

Regards,

      -s