World: r3wp

Yes.

If so, please mention that in a ticket comment.

It might be a compiler problem.

A library problem, yes.

Are you talking about R2 or R3?

Read what I said above: A110

Two tests in the example code given in the ticket seem wrong to me.

Right, sorry. I read that after I sent the message.

; Verification using SAME?
>> set [c d] sort reduce [a: "a" b: "a"]
== ["a" "a"]
>> same? c a
== false  ; should be true
>> same? c b
== true  ; should be false
>> same? d a
== true  ; should be true
>> same? d b
== false  ; should be false

The last two tests should be the other way round, no?

same? d a ; should be false
same? d b ; should be true

Fixed.

Thanks

Btw, by reading again your samples Brian, I think now it"s weird 
for a quick sort.
Not exactly what I expected....

At least on Linux, it definitely is a qsort.

It might be using the C library qsort.

Calling the C librabry's qsort(3).

Definitely mention that in a ticket comment. We might be able to 
make this a platform-specific ticket.

Not really, I fear.

qsort(3) is not guaranteed to be stable.

I mean, mention that it works on Linux, if that is what your tests 
reveal.

(Neither is it guaranteed to be a quicksort.)

That it works on Linux is pure coincidence.

I ran into the problem when I was sorting words in a block and the 
bindings mattered.

If we want SORT to be stable, the implementation will have to abandon 
the use of qsort(3).

That would explain why the ticket is still not fixed. Please mention 
this in a ticket comment - it might lead to changing its status.

You can of course hack stability into qsort() by falling back to 
comparing adresses if values are the same.

Not sure if Carl likes that :)

That won't work, because we are comparing EQUAL? (maybe plus /case), 
not SAME?.

Does qsort take a comparison function? If so, it might be a error 
in that function.

I'm talking about the C side of things here.

Same here - a C function pointer.

Then I don't understand your EQUAL?/SAME? remark.

If two elements are EQUAL?, fall back to comparing their addresses 
in memory.

Won't work for linked lists, will work for arrays stored consecutively.

Sorry, missed that. Yes, qsort takes a callback used for comparison. 
Here's the decl:


void qsort(void *base, size_t nitems, size_t size, int (*compar)(const 
void *, const void*));

Sorry, I just got that you were talking about using <= instead of 
<.

My remark above was to the effect: if two elements are EQUAL? compare 
their INDEX? instead. This may sound ridiculous in context of REBOL's 
SORT, but it is no problem in C.

As the comparison callback gets pointers to the elements anyway.

I still think that you need to write this stuff in a ticket comment. 
Writing it here will have no effect - the ticket is where the real 
discussion happens, and I don't seem to understand your argument 
well enough in this case to paraphrase you there.

I'm writing already.

All :) intended, of course.

In any case, I find this channel more fruitful for interactive discussion.

True. But Carl won't see it.

BrianH <And not well enough documented either. I don't really know 
how /compare works, not completely.>

Comparators and the stable-sort trick (-1, 0 +1) are documented here 
in an old change log. It never made it into the dictionary for SORT:
    http://www.rebol.com/docs/changes-2-5.html#section-72

Documentation request referencing that link added here: http://curecode.org/rebol3/ticket.rsp?id=1793

Thanks :)

Re -1 0 1 - as far as I remember, I read somewhere about negative, 
0, positive?

That works too:

>> sort/compare [20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 
1] func [x y] [case [x < y [3] x = y [0] 'else [-4]]]
== [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20]

Are we talking R2's sort or R3's sort here? I know for a fact that 
R2's sort is stable. Obviously you can't get a stable sort if you 
use a comparator function and you return a logic! value.