u:= [9,2,4,7]; concat! (u, [1,2,42]); end := rest(u,4); part:=rest(u,2);  setrest!(end, part);

Asking for the number of elements of u will exhibit lisp-implementation-dependend behaviour, ranging from an error to an infinite loop.

We should either fix the documentation (saying, that this is the case), or check for circularity. This could be done by calling LIST_-LENGTH instead of LENGTH in ILIST, for example.

According to the common lisp standard list-length returns nil if the list is circular.

http://www.lispworks.com/documentation/HyperSpec/Body/f_list_l.htm

On Mon, Sep 1, 2008 at 4:27 PM, Tim Daly wrote

In the documentation it states:

"Note that using the "#" operator on a list with cycles causes Axiom to enter an infinte loop"

See: http://axiom-developer.org/axiom-website/documentation.html in Volume 0: Axiom Jenks and Sutor p41

Using FriCAS built with GCL-2.6.8pre the difference between LENGTH and LIST-LENGTH seems to be negligible. Usingclisp, LIST-LENGTH actually seems a little faster.

w:=[random(2^31)$INT for i in 1..10^5];

)set message time on

for i in 1..10000 repeat integer(LENGTH(w)$Lisp)

Time: 0.01 (IN) + 3.09 (EV) + 0.03 (OT) = 3.13 sec

for i in 1..10000 repeat integer(LIST_-LENGTH(w)$Lisp)

Time: 4.13 (EV) = 4.13 sec

On sbcl 32bit, LIST-LENGTH is slower than LENGTH by a factor of roughly 1.25. (compared to gcl on my 32 bit machine, where the factor is 1.57! I'm surprised of the result above, that makes for a factor of 1.03...) I'm not sure whether this is negligible. However, for short lists, the difference really should be negligible...

Martin

Status: open => rejected