World: r3wp

This is R3.

SORT isn't stable in R3, but UNIQUE uses hash tables, not SORT.

>> unique reduce [use [c] [a: 'c] use [c] [b: 'c]]
== [c]
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] a
== true
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] b
== false

This seems to be pretty consistent.

It currently seems to be stable, yes.

My question is if anyone knows whether we are actually guaranteed 
that it is.

(In which case it should be mentioned in the docs.)

Given how it's implemented, I don't see how it could be other than 
first-come-first-included.

What about if it's implemented differently?

In other words:

Is it a bug if UNIQUE is not stable.

?

That would end up with bug reports like the ones for SORT not being 
stable. I would consider it a bug.

If it would be a bug otherwise, it is safe to document this behaviour.

The SORT not stable bug http://issue.cc/r3/1152is currently considered 
a "should fix before release" priority, btw.

Yes, SORT sucks, sort-a...

it would be nice to have a few sort algorythms out of the box.

That, too

The only way I can currently use R3 is by replacing SORT

Funny, me too :)

With a rewrite of Ladislav's msort. I'll probably publish it after 
a few more enhancements

I use a custom extension which stably wraps qsort :) I guess it is 
slower than msort, though :)

No idea, it works and it has hardly any effect on the total performance 
of my CMS, so I didn't test further

This is what I have so far:

; Extended Merge Sort, originally by Ladislav Mecir, 2004

context [
	set 'msort func [
		table [series!]
		/skip size [integer!]
		/compare columns [integer! block!]
		/reverse
	][
		unless skip [size: 1]

		if size < length? table [sort table  ; > 1 slot
			copy table
			(length? table) / size
			size
			either integer? columns [reduce [columns]] [columns]
			reverse
		]
		table
	]

	do-compare: func [
		row1 row2
		columns
		/local column a b
	][
		foreach column columns [
			unless equal? a: pick row1 column  b: pick row2 column [
				return all [b  any [not a  a < b]]
			]
		]
		true  ; Equal
	]

	sort: func [
		table shadow
		length [integer!]
		size
		columns
		reverse
		/local half middle
	][
		either length < 4 [  ; 2 or 3 slots

   if length = 3 [sort skip shadow size  skip table size  2  size columns 
   reverse]


   merge table  shadow 1  skip shadow size  length - 1  size columns 
   reverse
		][
			middle: size * half: make integer! length / 2
			sort shadow table half size columns reverse

   sort skip shadow middle  skip table middle  length: length - half 
    size columns reverse
			merge table
				shadow half
				skip shadow middle  length
				size columns reverse
		]
	]

	merge: func [
		table  shadow length  shadow2 length2
		size
		columns
		reverse
	][
		until [

   either either reverse [do-compare shadow2 shadow columns] [do-compare 
   shadow shadow2 columns] [
				table: change table  copy/part shadow size
				shadow: skip shadow size
				-- length
				zero? length
			][
				table: change table  copy/part shadow2 size
				shadow2: skip shadow2 size
				-- length2
				zero? length2
			]
		]
		change change table
			copy/part shadow  length * size
			copy/part shadow2  length2 * size
	]
]

BTW, the last Msort:

http://www.fm.tul.cz/~ladislav/rebol/msort.r

is a bit faster than the older version you used

Got an iterative msort-do for R3:

msort: func [s l /local mid end rest step][
    forskip s 2 [
        unless (compare s/1 s/2) [swap s next s]
    ]
    step: 2
    loop -1 + log-2 l [
        rest: forskip s step * 2 [
            merge s             step 
                  skip s step   step
            s
        ]
        unless empty? end: skip rest step [
            merge rest      step
                  end       length? end
        ]
        step: step * 2
    ]
]

Not fully tested though...sorry

* replace msort-do in Ladislav's implementation

Don't use forskip in R2, it's slow like hell

yeah... FORSKIP is really overkilll just source it and you'll be 
amazed at how much code there is for a loop!  


also don't use FORALL..... cause it calls FORSKIP.    always use 
UNTIL or WHILE in these cases.

but with R3, it's just fine

yeah... in R3 they're all native  :-)

Kaj, you should find a way to fire all the <copy/part ... > you're 
doing.
I would try to reuse the same buffer with something like:
>> append/part clear buff ...

I use this often, though you have to be sure to copy the result somewhere... 
or else you get really spectacular bugs.

this technique might also be task *unsafe*... It depends how functions 
will be shared amongst threads (copy or reference).

unless you submit the buffer as an argument, of course.

The copy/part's are an optimization of Ladislav's original version. 
I'll review the feedback here later

Wow, some bugfixing after looong months, cool :-)

>> sort/compare [d a c b] func [x [string!] y [string!]] [probe type? 
x x > y]
word!
word!
word!
word!
word!
word!
word!
== [d c b a]

This is also a problem in R2.

Typespecs ignored: http://issue.cc/r3/1516
Sort not stable in R3: http://issue.cc/r3/1152

Those are the two problems that I know of that affect the above code. 
Did you mean something else?

The second might not affect the code, if the == [d c b a] is not 
an error.

type specs ignored, is the problem.

Right, [d c b a] is the correct order. Yes, #1516 is a really big 
(security) problem.

Be sure to watch out for this too in R3: http://issue.cc/r3/1100

Thanks

nothing since Nov?

nothing since Nov?

bug fixing mode right now, and Carl is looking into encryption and 
SSL.

why SSL and encryption?

Carl should get beta list out, not just choose another priority for 
next 3 months and then disappear again ...

Because there is a process of determining how it should be done and 
it might make sense to prepare for it now. There are several possibilities 
for implementation.

really, if we have to choose between encryption and threads... there 
is no contest.... all the "usability" stuff we can code as extensions 
and indeed, the cURL binding is a good example of this.


we need threads to be done... they have an over-arching effect on 
every aspect of REBOL... we can't put this off until later... its 
going to change the design of things for sure.  I can't understand 
why Carl is side-stepping this again.