r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Gabriele
24-Jan-2011
[7310]
Oldes, a perhaps simpler version for R2 is: http://www.rebol.it/power-mezz/mezz/form-error.html

I thought FORM was supposed to be able to do the same thing on R3, 
not implemented yet?
Oldes
24-Jan-2011
[7311]
You are right... simple FORM err works:

>> error? err: try [1 / 0]
== true

>> form err
== {** Math error: attempt to divide by zero
** Where: / try
** Near: / 0
}
Kaj
24-Jan-2011
[7312]
Oh, cool
Andreas
26-Jan-2011
[7313]
Anyone happens to know whether UNIQUE is guaranteed to be stable 
for blocks? I.e. if we're guaranteed that the result block has the 
elements in the same order they first appeared in the original block?
Maxim
26-Jan-2011
[7314]
in my tests (which I did this week) it was stable in R2.
Andreas
26-Jan-2011
[7315]
This is R3.
BrianH
26-Jan-2011
[7316x2]
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.
Andreas
26-Jan-2011
[7318x3]
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.)
BrianH
26-Jan-2011
[7321]
Given how it's implemented, I don't see how it could be other than 
first-come-first-included.
Andreas
26-Jan-2011
[7322x4]
What about if it's implemented differently?
In other words:
Is it a bug if UNIQUE is not stable.
?
BrianH
26-Jan-2011
[7326]
That would end up with bug reports like the ones for SORT not being 
stable. I would consider it a bug.
Andreas
26-Jan-2011
[7327]
If it would be a bug otherwise, it is safe to document this behaviour.
BrianH
26-Jan-2011
[7328]
The SORT not stable bug http://issue.cc/r3/1152is currently considered 
a "should fix before release" priority, btw.
Kaj
26-Jan-2011
[7329]
Yes, SORT sucks, sort-a...
Maxim
26-Jan-2011
[7330]
it would be nice to have a few sort algorythms out of the box.
Kaj
26-Jan-2011
[7331x2]
That, too
The only way I can currently use R3 is by replacing SORT
Andreas
26-Jan-2011
[7333]
Funny, me too :)
Kaj
26-Jan-2011
[7334]
With a rewrite of Ladislav's msort. I'll probably publish it after 
a few more enhancements
Andreas
26-Jan-2011
[7335]
I use a custom extension which stably wraps qsort :) I guess it is 
slower than msort, though :)
Kaj
26-Jan-2011
[7336x3]
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
	]
]
Ladislav
27-Jan-2011
[7339]
BTW, the last Msort:

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

is a bit faster than the older version you used
Steeve
27-Jan-2011
[7340x3]
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
Maxim
27-Jan-2011
[7343]
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.
Steeve
27-Jan-2011
[7344]
but with R3, it's just fine
Maxim
27-Jan-2011
[7345]
yeah... in R3 they're all native  :-)
Steeve
27-Jan-2011
[7346]
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 ...
Maxim
27-Jan-2011
[7347x2]
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.
Kaj
27-Jan-2011
[7349]
The copy/part's are an optimization of Ladislav's original version. 
I'll review the feedback here later
Pekr
31-Jan-2011
[7350]
Wow, some bugfixing after looong months, cool :-)
Henrik
31-Jan-2011
[7351]
>> 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.
BrianH
31-Jan-2011
[7352x2]
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.
Henrik
31-Jan-2011
[7354]
type specs ignored, is the problem.
BrianH
31-Jan-2011
[7355x2]
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
Henrik
31-Jan-2011
[7357]
Thanks
Mchean
2-Feb-2011
[7358x2]
nothing since Nov?
nothing since Nov?