does sort always sort vectors in place?
in [Lisp]
|
From: Captain Obvious on 26 Apr 2010 05:19 ??>> "The sorting operation can be destructive in all cases. In the case of ??>> a vector argument, this is accomplished by permuting the elements in ??>> place. In the case of a list, the list is destructively reordered in ??>> the same manner as for nreverse." ??>> ??>> It is unclear whether sorting vectors in place is an option ("can be ??>> ...") or it is always done that way. To put it differently, if V is ??>> known to be a vector, do I have to use ??>> ??>> (setf v (sort v predicate)) ??>> ??>> or can I just rely on ??>> ??>> (sort v predicate) ??>> ??>> to achieve the same effect? PC> Yes, the latter. The wording "can be" seems to be a defense of the PC> design choice to make sort destructive. I think "can be" there merely means that if sequence is already sorted, it just won't touch it.
From: Pascal Costanza on 26 Apr 2010 06:06 On 26/04/2010 11:19, Captain Obvious wrote: > ??>> "The sorting operation can be destructive in all cases. In the case of > ??>> a vector argument, this is accomplished by permuting the elements in > ??>> place. In the case of a list, the list is destructively reordered in > ??>> the same manner as for nreverse." > ??>> > ??>> It is unclear whether sorting vectors in place is an option ("can be > ??>> ...") or it is always done that way. To put it differently, if V is > ??>> known to be a vector, do I have to use > ??>> > ??>> (setf v (sort v predicate)) > ??>> > ??>> or can I just rely on > ??>> > ??>> (sort v predicate) > ??>> > ??>> to achieve the same effect? > > PC> Yes, the latter. The wording "can be" seems to be a defense of the > PC> design choice to make sort destructive. > > I think "can be" there merely means that if sequence is already sorted, > it just won't touch it. Nope. The spec clearly says that the result may not be identical to the first parameter. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: RG on 26 Apr 2010 10:51 In article <83l6u0FmilU1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > On 26/04/2010 11:19, Captain Obvious wrote: > > ??>> "The sorting operation can be destructive in all cases. In the case of > > ??>> a vector argument, this is accomplished by permuting the elements in > > ??>> place. In the case of a list, the list is destructively reordered in > > ??>> the same manner as for nreverse." > > ??>> > > ??>> It is unclear whether sorting vectors in place is an option ("can be > > ??>> ...") or it is always done that way. To put it differently, if V is > > ??>> known to be a vector, do I have to use > > ??>> > > ??>> (setf v (sort v predicate)) > > ??>> > > ??>> or can I just rely on > > ??>> > > ??>> (sort v predicate) > > ??>> > > ??>> to achieve the same effect? > > > > PC> Yes, the latter. The wording "can be" seems to be a defense of the > > PC> design choice to make sort destructive. > > > > I think "can be" there merely means that if sequence is already sorted, > > it just won't touch it. > > Nope. The spec clearly says that the result may not be identical to the > first parameter. No, it says it *might* not be identical. Subtle but crucial difference. rg
From: Peter Keller on 26 Apr 2010 11:36 RG <rNOSPAMon(a)flownet.com> wrote: > In article <83l6u0FmilU1(a)mid.individual.net>, > Pascal Costanza <pc(a)p-cos.net> wrote: > >> On 26/04/2010 11:19, Captain Obvious wrote: >> > ??>> "The sorting operation can be destructive in all cases. In the case of >> > ??>> a vector argument, this is accomplished by permuting the elements in >> > ??>> place. In the case of a list, the list is destructively reordered in >> > ??>> the same manner as for nreverse." >> > ??>> >> > ??>> It is unclear whether sorting vectors in place is an option ("can be >> > ??>> ...") or it is always done that way. To put it differently, if V is >> > ??>> known to be a vector, do I have to use >> > ??>> >> > ??>> (setf v (sort v predicate)) >> > ??>> >> > ??>> or can I just rely on >> > ??>> >> > ??>> (sort v predicate) >> > ??>> >> > ??>> to achieve the same effect? >> > >> > PC> Yes, the latter. The wording "can be" seems to be a defense of the >> > PC> design choice to make sort destructive. >> > >> > I think "can be" there merely means that if sequence is already sorted, >> > it just won't touch it. >> >> Nope. The spec clearly says that the result may not be identical to the >> first parameter. > > No, it says it *might* not be identical. Subtle but crucial difference. Usually, programming language specs define terms like "should", "may", and "might". Is there a definition of these terms in the HS? I can't find them. -pete
From: Paul Wallich on 26 Apr 2010 11:55 Peter Keller wrote: > RG <rNOSPAMon(a)flownet.com> wrote: >> In article <83l6u0FmilU1(a)mid.individual.net>, >> Pascal Costanza <pc(a)p-cos.net> wrote: >> >>> On 26/04/2010 11:19, Captain Obvious wrote: >>>> ??>> "The sorting operation can be destructive in all cases. In the case of >>>> ??>> a vector argument, this is accomplished by permuting the elements in >>>> ??>> place. In the case of a list, the list is destructively reordered in >>>> ??>> the same manner as for nreverse." >>>> ??>> >>>> ??>> It is unclear whether sorting vectors in place is an option ("can be >>>> ??>> ...") or it is always done that way. To put it differently, if V is >>>> ??>> known to be a vector, do I have to use >>>> ??>> >>>> ??>> (setf v (sort v predicate)) >>>> ??>> >>>> ??>> or can I just rely on >>>> ??>> >>>> ??>> (sort v predicate) >>>> ??>> >>>> ??>> to achieve the same effect? >>>> >>>> PC> Yes, the latter. The wording "can be" seems to be a defense of the >>>> PC> design choice to make sort destructive. >>>> >>>> I think "can be" there merely means that if sequence is already sorted, >>>> it just won't touch it. >>> Nope. The spec clearly says that the result may not be identical to the >>> first parameter. >> No, it says it *might* not be identical. Subtle but crucial difference. > > Usually, programming language specs define terms like "should", "may", and > "might". Is there a definition of these terms in the HS? I can't find them. This is associativity problem. "X may Y" is essentially the same as "X might Y" _except_ when Y is a compound of the form "not Z". Then it is textually indistinguishable from "X may not Z", which in turn is essentially "X must (not Z)" rather than "X might (not Z)". paul copyediting is such fun
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: questions about packages Next: Comprehending error messages |