World: r3wp

I know, that it is documented somewhere, that the Comparator can 
yield either logic! value or a number, where a negative number means 
"<", zero means "=", and a positive number means ">"

Btw, Linux A110's SORT seems rather stable for me :)

using the example Brian gave?

Read the ticket. "Stable" means a different thing when applied to 
sorting algorithms.

Thanks Brian, I'm fine with terminology here.

No offence intended :)

I guess I wouldn't have told you about std::sort being unstable, 
if I wouldn't know what a stable sort is?

Yes Ladislav, for all examples in that ticket.

Sorry, momentary lack of humor. Did you mean that it works correctly 
on Linux?

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.