Am Mittwoch, den 07.01.2009, 22:16 -0700 schrieb Robert Dodier:
> On Wed, Jan 7, 2009 at 7:20 PM, Harald Geyer <harald at lefant.net> wrote:
>
> I am confused as well --- I don't see what problem is illustrated by
> the example.
>
Yes, now I am confused too. I have done a wrong conclusion.
I have worked on the bug report SF[887639] "listarray when
use_fast_arrays : true". But I have done this work only with GCL and not
CLISP. Thus I have not seen that I have got a special problem with GCL
(+ Windows?).
At first again the example from a post of the bug report:
use_fast_arrays: true$
b: [1,2]$
b[3] => error OK
b[3]: 5$ => no error ???
b[3] => error ???
b => [1,2] ??? setting b[3] didn't give an error, but has no
effect on b
c[1]: 5$
c => #<hash-table 234234234> (ridiculous internal thingy
This example was done with GCL-2-5.0 and Maxima 5.9.0
1. I did not recognize that it is possible to set the elements of a
Maxima list like an array e.g. (is this documented?)
(%i1) a:[1,2,3,4,5];
(%o1) [1,2,3,4,5]
(%i2) a[3];
(%o2) 3
(%i3) a[3]:333;
(%o3) 333
(%i4) a;
(%o5) [1,2,333,4,5]
2. There is a difference using use_fast_arrays:false or true. In the
case of false we get a Maxima error when we try to set a value with
wrong index. When we use_fast_arrays:true we get a Lisp error (not for
GCL).
(%i45) use_fast_arrays:false;
(%o45) false
(%i46) a:[1,2,3];
(%o46) [1,2,3]
(%i48) a[5]:5;
5 - index out of range
-- an error. To debug this try debugmode(true);
(%i49) use_fast_arrays:true;
(%o49) true
(%i50) b:[1,2,3];
(%o50) [1,2,3]
(%i52) b[5]:5;
Maxima encountered a Lisp error:
(SETF NTH): index 5 is too large for ((MLIST SIMP) 1 2 3)
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.
3. If I try the above example with GCL 2.6.8 I can get something like
(%i6) use_fast_arrays:true$
(%i7) b:[1,2,3]$
(%i8) b[4]:4; /* No error message */
(%o8) 4
(%i9) b;
(%o9) [1,2,3] /* Nothing has happened? */
(%i14) c[1]; /* Some expressions later. */
Universal error handler called recursively (:ERROR NIL ...
At this point the Maxima session is killed.
At first it seems that nothing had happened like in the bug report. But
that is not true. The memory is damaged. When I continue the session
first a lot of strange things can happen. Some time later the session is
killed.
This does not happen when using use_fast_arrays:false. In this case
Maxima gives correct error messages when the index is wrong.
Result:
With use_fast_arrays:true Maxima uses a different algorithm to check the
index and to access the list values.
With GCL the memory is damaged when we try to write into the list with a
wrong index.
So I think for the case fast_arrays:true a check of the correct index
has to be added to avoid a Lisp error e.g. for CLISP and a memory damage
for GCL.
Dieter Kaiser