AltME groups: search

change c b pick L either-zero v 1 [either-zero h 2 [either-equal 
h v 3 4]]

i think that feature (2 different centers) is not used that much.

In the lizard.svg example i gave, they don't use it, the 2 centers 
are always equal.

http://www.dobeash.com/RebDB/rebdb3.html#section-4.6gives a brief 
but complete idea of how indexing works. The low-level implementation 
is quite simple:


 - The index is a binary! with each n bytes (n = idx-size, defaulting 
 to 2) representing on offset into the data binary! (start of row).

 - The index is sorted by/with a number of columns (left to right) 
 equal to the number of key columns (minimum of 1).
	- Updates and inserts that break this order set a reindex flag.

 - Lookup and seek both check the reindex flag prior to searching 
 the index binary! using a binary search ( http://en.wikipedia.org/wiki/Binary_search_algorithm
 ).

 - Lookup returns a single row (where # key values = # key columns)

 - Seek uses Lookup to return a range of values (where # key values 
 <> # key columns) and then does a linear match on each row


I'll devote a bit more time/space in the documentation to flesh this 
out with examples.

The index [of offsets] is created by reading a number of columns 
(min 1) equal to key-cols and inserting both the composite row and 
the offset into a block which is then sorted by the composite row. 
For eaxmple:


Say we have 2 columns of integers in the index and also assume we 
have two rows.

Reading:

	3 2 ...
	2 3 ..

might create an intermediate block like:

	#{0034} #{01030102}	; note the #{01} field length indicators}
	#{0056} #{01020103}

which is sorted to produce an index of:

	#{00560034}


Index is updated as rows are inserted or deleted. Some insert and 
update operations will set a reindex flag which is acted upon the 
next time a lookup or seek is performed.


This index is maintained automatically by RebDB ... you cannot "create" 
one in the traditional sense of the word. The weakness of this scheme 
is it assumes that key access is by column 1 OR column 1 & column 
2. It doesn't handle the situation where you need key access to column 
1 OR column 2 (which in my experience is a fairly uncommon case).

for random 1.0 you cannot find any irregularities, there aren't any


I think, there are. Decimals with a certain exponent are equal spaced, 
but there are many different exponents involved going from 0.0 to 
1.0. The first normalized decimal is:

>> to-decimal #{0010 0000 0000 0000}
== 2.2250738585072e-308

The number with the next exponent is:

>> to-decimal #{0020 0000 0000 0000}
== 4.4501477170144e-308

I can take the difference:


>> (to-decimal #{0020 0000 0000 0000}) - to-decimal #{0010 0000 0000 
0000}
== 2.2250738585072e-308

and see the difference double with every new exponent:


>> (to-decimal #{0030 0000 0000 0000}) - to-decimal #{0020 0000 0000 
0000}
== 4.4501477170144e-308

>> (to-decimal #{0040 0000 0000 0000}) - to-decimal #{0030 0000 0000 
0000}
== 8.90029543402881e-308

>> (to-decimal #{0050 0000 0000 0000}) - to-decimal #{0040 0000 0000 
0000}
== 1.78005908680576e-307

So doing
random 1.0

many times with the current random function will favorize 0.0 a great 
deal. The consequence is, 0.0 will come out many more times than 
the first possible numbers just above 0.0, and the mean value will 
be a lot lower than 0.5.

Oh! Yes, I didn't have that in mind. So the smallest result larger 
than zero from RANDOM 1 is:

>> tt62: to integer! 2 ** 62
>> 1 / tt62
== 2.16840434497101e-19

It's still smaller than 1.11022302462516e-16

Can RANDOM 1.0 produce a result equal to 1.0 - 1.11022302462516e-16 
?

hi, please check http://www.rebol.net/wiki/Comparisons, I am e.g. 
unusure about the relation between timezone and STRICT-EQUAL?

I would have thought that strict-equal? would imply the same timezone.

I would have thought EQUIVALENT? would imply the same time zone, 
or at least some time zone math. Certainly STRICT-EQUAL?.

It's a recent bug fix. Wait, isn't STRICT-EQUAL? supposed to be EQUIVALENT? 
plus a datatype check? Then if EQUIVALENT? already does zone math 
I vote that STRICT-EQUAL? do zone math and SAME? do precise equivalence.

so, more differences between Strict-equal? and Equivalent?

you mean to add the distinction of timezone to Strict-equal? - yes 
looks natural

OK, *adding the timezone distinction to Strict-equal?*

Ladislav, the cyclic structures above are not the same structure, 
but the results would need to be considered EQUAL?. Unless we declare 
that cyclic structures need to have the same structure to be declared 
equal - then we can use a stack of ref/index for the structure detection.

try this in R3


>> do http://www.rebol.org/download-a-script.r?script-name=identity.r
Script: "Identity.r" Version: none Date: 7-May-2009/8:59:07+2:00
Script: "Contexts" Version: none Date: 12-May-2006/15:58+2:00
Script: "Closure" Version: none Date: 11-May-2009/19:13:51+2:00
Script: "Apply" Version: none Date: 7-May-2009/9:25:31+2:00
== make function! [[
    "finds out, if the VALUE is mutable"
    value [any-type!] /local r
][
    parse head insert/only copy [] get/any 'value [

        any-function! | error! | object! | port! | series! | bitset! |
        struct! | set r any-word! (
            either bind? :r [r: none] [r: [skip]]
        ) r
    ]
]]

>> a: [z] append/only a a
== [z [...]]

>> b: [z [z]] append/only second b second b
== [z [...]]

>> c: [z [z]] append/only second c c
== [z [z [...]]]

>> equal-state? a a
== true

>> equal-state? a b
== true

>> equal-state? a c
== true

search for EQUAL-STATE?

In any case, for R3 line 502:
            if strict-not-equal? mold :a mold :b [return false]
should probably be this:
            if not-equal? mold :a mold :b [return false]

depends on the level of strictness we want to achieve for the said 
EQUAL-STATE? function...

Unless you want
>> equal-state? [A] [a]
== false

Well, my point was that marking isn't enough here, and that this 
kind of comparison (the kind in equal-state?) is needed.

You would have to do something similar to a simplified EQUAL-STATE? 
even in a C version. There will never be enough bits for marking 
because every concurrent instance of your comparison would need its 
own set. Having thread-local done lists would work though.

OK, EQUAL-STATE? is too strict in another way: It also considers 
values that precede the series references. I'm going to figure out 
if it will still work if changed to use the level of equivalence 
expected from EQUAL?. Note:
>> equal? next [a a] next [b a]
== true
>> equal? next [a a] next 'b/a
== false
Not sure about that last one - will it be true in R3?

It looks like an algorithm similar to EQUAL-STATE? will work for 
structural equivalence if you get rid of lines 518 and 519. Some 
of the comparisons should be relaxed to the same level as the comparison 
function you are implementing too. I notice that it does topological 
similarity rather than strict structural equivalence :)

these index issues - there are simply too many variants of equality 
- the Equal-state? comparison is certainly unrelated to any of the 
currently proposed hierarchy levels

(it looks to me like a level slightly above Strict-equal?, but below 
Same?)

Ladislav, I've tested random some more. The equal sign, =, is used 
to test in the end of RANDOM, if the result should be changed to 
0.0. This will change more values, than if =? was used. I use =? 
in my test. My test goes like this:

REBOL [
	Title:		"Random distribution test"
	Author:		"John Niclasen"
]

random/seed now
dist: clear []	; distribution
tt62: to integer! 2 ** 62
a: tt62 - 1024
loops: 100000
loop loops [
	i: random 1024
	if i > 512 [i: i + a]	; test close to 0.0 and close to 1.0
	y: i - 1 / tt62 * 1.0
	if y =? 1.0 [y: 0.0]	; the result of random 1.0
	y: form y
	either find dist y [
		dist/:y: dist/:y + 1
	][
		repend dist [y 1]
	]
]
while [not tail? dist] [
	dist/1: load dist/1		; change strings back to decimals
	dist: skip dist 2
]
dist: head dist
sort/skip dist 2	; sorting distribution
print dist
mean: 0.0
foreach [value count] dist [
	mean: value * count + mean
]
mean: mean / loops	; calculating the mean value
print mean	; this should be 0.5


The test is testing values close to 0.0 and close to 1.0. Notice 
the high count of 0.0 result compared to other low values. Also notice, 
how the mean value is close to 0.25, where it should be 0.5. Try 
out-comment the change of y to 0.0. Then the result will be much 
better.

The equal sign, =, is used to test in the end of RANDOM, if the result 
should be changed to 0.0.

 - actually, you caught my doc translation error (the code is in C 
 and I "automatically converted" == to =, which does not correspond 
 well

re the equal sign - see the corrected http://www.rebol.com/r3/docs/functions/random.html

Maybe for equal, but I'm not sure with greater-than and less-than.

so basically, you build a little module in cheyenne which does a 
tcp exchange to your R3 server.  

the R3 server maps the request to a module, returns the molded result.

cheyenne then returns the value in an xml block which your ajax app 
did the request for.


allowing multiple handlers on the cheyenne side (and an equal amount 
of R3 servers) would allow you to support multiple concurrent users, 
but you'd have to map which R3 service is being used within the cheyenne 
module, in order to send your tcp request to a free R3 service.

does any of this make sense?

I don't understant, the following parsings should be equal but it's 
not, why ???

parse a: "abcdef" [
    any [
          "b" remove -1
        | "cd" remove -2
        | skip
    ]
]
print a
parse a: "abcdef" [
    any [start: 
          "b" remove start 
        | "cd" remove start
        | skip
    ]
]
print a

You created a bitset of just one byte. When you append 1 to the bitset, 
you set the bit representing position 1 in the bitset, so you get 
#{40}, which is equal to binary: 2#{01000000}
Position 0 in the bitset is the first bit. Example:

>> bits: append make bitset! 1 0
== make bitset! #{80}

which is equal to binary: 2#{10000000}

Note that bitsets have changed in R3!

I also tested, that it takes equal amount of cpu time to do this 
in C, where a and b are of type double:

fmod (a, b)

or

a - floor (a / b) * b

Same can be said for integers, where we would use % in C.

Another thing, we have pi:

>> pi
== 3.14159265358979

Would it be an idea to have e equal to:

>> exp 1
== 2.71828182845905

I mean, we can create pi ourselves with

arccosine/radians -1

, so why is pi there? And if it is, why isn't e there?

I still find the equal operator with its trying to be clever about 
rounding errors in decimals a strange thing. Try this example:

for i 4.0 6.0 0.1 [print i if i = 6.0 [print [i "= 6.0"]]]

The last line output is:

5.99999999999999 = 6.0


So those two numbers are the same for the equal operator. Let's check 
it:

>> 5.99999999999999 = 6.0
== false

Now see what happens, if I let the loop run a little longer:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


Now the equal test within the loop doesn't become true. The last 
number output is 6.99999999999999, so this number doesn't equals 
7.0, like 5.99999999999999 equals 6.0. I know, we don't see all possible 
decimals, but that's not my point. My point is, that if equal can't 
cope with rounding errors always, then it shouldn't try to do it 
at all. (My opinion.) The current behaviour isn't a good thing for 
the language.

I'm questioning the "nearness" in equal. Another example:

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 - 0.3 = 0.0
== false


STRICT-EQUAL returns false for both of these. Is the "nearness" a 
good thing to have from a language design point of view?

Btw, worker processes are not equal wrt the load. The first in the 
list gets the more jobs to do, especially if requests can be processed 
fast (which should be the case in most of well-coded scripts). So, 
you get a natural "affinity" to the first worker (having the most 
code and data cached there) for all new incoming requests. 

So, in the long run, you can look at workers memory usage to see 
how the workload is spread, the first one having the biggest memory 
usage, the last one having the lowest. Looking at the last one is 
a good indicator if the number of workers needs to be raised or not, 
if his memory footprint hasn't changed since the last restart, your 
server is doing fine with the load. I should expose some workers 
and job queue usage stats to help fine tune workers numbers.

All men are created equal

the problem is that if somehow JavaScript would be given equal/significant 
standing in REBOL, maybe it's harder to make the case for needing 
REBOL in the first place

I suppose that in an environment like Android, REBOL apps could have 
equal opportunity to HTML5 apps - so the best tech should win.

AGG interface is speeded up. Current gain about 280% faster. As you 
can see the drawing time is about 3 times the resizing time. These 
numbers should become more equal.

For example: If you can't get AGG to work, you need to do a replacement 
with an equal API layer.

a discussion we had yesterday about how to produce that layout. the 
SPACING parameter would produce a space around all red squares equal 
in size to the spacing between the squares. this has been changed, 
so that space is not produced and one must use PADDING instead.

Why is "foo" equal?/= "FOO" but "foo" not strict-equal?/== "FOO" 
?

Andreas, strict-equal? does case-sensitive comparison. That's why 
it's a separate function :)

Will report a bug that the docstrings of equal? and strict-equal? 
are extended to mention behaviour wrt case.

The current docstrings:
equal?: "... if the values are equal"

strict-equal?: "... if the values are equal and of the same datatype."

I will figure out a way how to squeeze a case sensitivity remark 
into the strict-equal?

if the values are EQUAL

uses no more characters

Two suggestions:

>> length? "TRUE for values that are equal and of the same case and 
datatype." 
== 65

>> length? "Returns TRUE for EQUAL? values that are of the same case 
and datatype."
== 70

>> strict-equal? 1-Jan-2010 1-JANUARY-2010
== true

Yeah, I guess it's a question of what would be considered more irritating: 
STRICT-EQUAL?s docstring pretending that it only differs from EQUAL? 
in that it also considers the datatype. Or mentioning case-sensitivity 
explicitly.

instead of strict-equal?

You can't have an op! call a function with a refinement. STRICT-EQUAL? 
is only there to be the prefix form of ==.

>> strict-equal? 'a 'A
== false

On STRICT-EQUAL?, I'll also cast my vote that keeping doc strings 
short is a good idea. But if a doc string is unclear, incomplete, 
or just plain wrong just so it won't wrap on a text console in a 
HELP listing, Our priorities are severely out of whack.. Let me know 
if I need to take that opinion directly to Carl.

Gregg, as for the STRICT-EQUAL? doc string length limit not allowing 
us to have its most important behavior mentioned, we don't have evidence 
yet that this is the case, and it seems unlikely. Noone mentioned 
the case sensitivity needing to be there before, and now noone has 
tried to phrase the doc string accordingly. I suggested that a documentation 
ticket be submitted with new phrasing, and just mentioned the limit 
(and its rationale) for the information of the person doing the submitting.


We need to have some limit on the length doc strings for a variety 
of reasons, not the least of which is that it is good to be concise. 
Many built-in functions can't have thorough documentation in their 
doc strings no matter how long we make them. The doc string is just 
a smmary for some functions, a reminder for others. The full docs 
should go on the web site accessible from HELP/doc. And if there 
isn't a web site for one of the system words, or if it's wrong or 
outdated (which is a lot at this stage) then report it.

Brian, agreed. My point was that we should'nt have a fixed limit 
of 70 characters (for example) that prevents us from using 75 characters 
for a func that really needs it. STRICT-EQUAL? was just the example 
at hand.

A correction to BrianH's STRICT-EQUAL? response: "noone has tried 
to phrase the doc string accordingly" is factually incorrect, as 
can be easily seen in the log. I posted two rephrasal suggestions.

The two suggestions from Andreas:


1) "TRUE for values that are equal and of the same case and datatype." 

2) "Returns TRUE for EQUAL? values that are of the same case and 
datatype."

I'll add the following option:


Returns TRUE for values that are equal and of the same case and datatype.
 


Which is just Andreas's #1 with "Returns" at the head, to match the 
doc string for EQUAL? and others.  That makes it 73 chars total. 
I don't think that's a problem, but I also don't think it's neccessary 
in this case. It wouldn't hurt of course, but certain information 
may have to be elided from doc strings, and this piece of information 
for STRICT-EQUAL? is easy to deduce and understand IMO.

Returns TRUE if the values are equal.

And regarding the necessety, maybe it's just me, but when I compare:
- Returns TRUE if the values are equal. 
- Returns TRUE if the values are equal and of the same datatype. 

I would deduce that "and of the same datatype" is the only difference 
between those functions. I personally have been with REBOL long enough 
to know that this is not true, but I still think that these docstrings 
in this case are misleading.

Andreas, what about something like one of these:


- "Returns TRUE if the values are strictly equal and of the same 
datatype." 

- "Returns TRUE if the values are strictly equal and the same datatype." 

- "Returns TRUE if the values are strictly equal, including their 
datatype." 

- "Returns TRUE if the values are strictly equal, including datatype." 


We can argue that just adding the word "strictly" doesn't help, but 
then the help for EQUAL? isn't very helpful either. :-) My thinking 
here is that there are a number of things that may seem confusing 
about strict equality, and we can't address them all in the doc string. 
Case sensitivity is important, and if we want to single that out, 
I'm OK with it, but might there be other cases as well?

>> strict-equal? d1 d2
== true
>> d1
== 16-Feb-2010/13:25:30-7:00
>> d2
== 16-Feb-2010/14:25:30-6:00
>> equal? [a] [A]
== true
>> strict-equal? [a] [A]
== false
>> strict-equal? 'a 'A
== true 


R3 addresses those cases, but are there others? What about user defined 
types (not sure what the status or goal is on utype! values at this 
point)?

Yes, just rephrasing the strict-equal? docstring as "Returns TRUE 
if the values are strictly equal." woul also be an option

But actually, I quite like "Returns TRUE if the values are strictly 
equal." This does not lead a user who reads only the docstring to 
wrong conclusions.

I updated the docbase "comparisons" page to reflect this: http://www.rebol.net/wiki/Comparisons#EQUAL.3F

Added a comment to that ticket, with a suggestion for doc strings 
that fit the limit:

- STRICT-EQUAL? "Returns TRUE if the values are equal and of the 
same datatype, case."

- STRICT-NOT-EQUAL? "Returns TRUE if the values are equal and of 
the same datatype, case."

Nice, consise, and 68 and 69 characters, respectively, no problem. 
You can even change "datatype, case" to "datatype & case".

STRICT-EQUAL? == STRICT-NOT-EQUAL?

And you can use STRICT-NOT-EQUAL? as a function value if need be, 
but not NOT STRICT-EQUAL?.

Returns TRUE if the values are equal and of the same datatype, case.

That ending doesn't read very well to me.

Brian, if "Returns TRUE if the values are equal and of the same datatype 
& case." is OK, but "Returns TRUE if the values are equal and of 
the same datatype and case." is not, that's where I think uor priorities 
are out of order. 


Maybe the first thing we should do is write a clear goal for doc 
strings. What is their main purpose and what constraints should be 
placed on them for each purpose (or maybe I just haven't seen the 
doc that does this)? For example, are they be limited for console 
output only when listed with other funcs, or also when used with 
HELP individually? Should ? be short help and ??? link to a detailed 
help page for funcs? If console group list is the constraining factor, 
can it truncate and ellipsize longer strings?

what you say is equal to:

a: [1 2 3 4 5 6]
a/3
== [3]

BrianH: now I will get you ... what value should to-integer #{8000} 
return? It now returns 32768!!! And according to your theory, it 
should be equal to padded value, hence to-integer #{8000000000000000}, 
because you just said, that I can't expect #{8000} to be the lowest 
bytes ...

ChristianE, It seems like an oversight to me. We aren't doing the 
SQL-style "null doesn't equal anything, even other nulls" model in 
REBOL.

not saying single be removed... its just like   empty? and tail? 
  they have different semantic meanings, but in rebol are equal in 
implementation.

the only thing I find funny about the FUNCT  is that pretty much 
everyone prefers something else  (sorry Gregg ;-)   


maybe Carl chose it knowing that everyone one would feel equal  ;-)

(I have no gripe with the path notation. It's the old strict-equal? 
issue the above was hinting at.)

INFs are a low priority.....But they are also an interesting REBOL 
phenomena...Unserialisable values that do not always equal other 
same-sized INFs :)

    xx: array/initial 100 as-pair 1e44  -1e44
    length? unique xx

    == 100   ;; 100 separate infinities ... Cantor would be proud!

    (first xx/1) = (first xx/1)
    == true
    (first xx/1) = (first xx/2)

    == true           ;; or perhaps its just UNIQUE having a bad day

    xx/1 = xx/2     ;; or perhaps not
    == false

we can't comment its reviewed... but I would call it  diff   not 
compare.


since if they are equal it would return none, its a much better word 
than compare.

if not diverge? seriesa seriesb [ print "they're equal mate!" ]

Now that I have internet again (it's been out for possibly a week) 
I'll check with Carl about this, but I remember code from 2007-2008 
that depended on this change, even from before SELECT was extended 
to objects and maps. It's used to make blocks that look like spec 
blocks for objects or maps act like objects or maps. SELECT does 
EQUAL? comparison, and SELECT/case does STRICT-EQUAL? comparison. 
So you can make it work by using SELECT/case. Note: Words now support 
case-sensitivity in blocks too, letting them be searched with FIND/case 
and SELECT/case.

I'm not sure it's completely OK though, since there is one part of 
strict comparison that SELECT/case doesn't cover: binding.
>> select/case reduce [use [a] ['a] 1 'a 2] 'a
== 1
>> strict-equal? use [a] ['a] 'a
== false

Nor do we want it to, because SELECT, FIND and other functions to 
which /strict would apply would generally not be applied to data 
which could be guaranteed to have the same binding as the value you 
are searching for.

; 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
	]
]

Actually I ran into problems related to this, when programming the 
bparse function. At one point, I need to test, if a token variable 
is equal to the word END. To specify the word END, I write it as 
a lit-word, because lit-words are changed to words on the run. I 
need to use == to compare, because I want the type to be the same 
too. So I would expect, this is the correct test:

	token == 'end

Let's test:

>> token: first [end]
== end
>> token == 'end
== true

Seems to work, but then the surprise, if token is a lit-word:

>> token: first ['end]
== 'end
>> token == 'end      
== true

Also true? Hmm, so I have to write:

>> :token == 'end
== false

Of the 3, SECURE seems like the most likely to be enhanceable with 
capabilities. Functions could be enhanced by capabilities specs, 
where the function code could only create other functions of equal 
to or lesser capabilities than are currently available in the call 
stack. Once a function is created, it could run code with the capabilities 
that it was created with (with the exception of that function creation 
limitation earlier). There could be a function like DO that reduces 
capabilities and then does a block of code, and maybe MAKE module! 
could be made to use that function based on capabilities in the module 
spec.

I figured out a new way to express the equivalence that can safely 
be used for word! (http://issue.cc/r3/1882), path! (http://issue.cc/r3/1881), 
lit-word! and lit-path! (http://issue.cc/r3/1434), set-word! and 
set-path! (http://issue.cc/r3/1883), and get-word! and get-path! 
(current behavior), that matches the behavior of paren!. This code 
should work in all cases.

use [a b] [
    a: func [] ["blah"]

    foreach t compose [(paren!) (to-block any-word!) (to-block any-path!)] 
    [

        assert [any [all [error? try reduce [to t 'a] error? try [do to t 
        'a]] same? do reduce [to t 'a] do to t 'a]]
        assert [b: to t 'a strict-equal? to t 'a b]
    ]
]


Basically, the equivalence of an individual type would be this (using 
word! as an example):
    same? do [a] do 'a
    b: 'a same? 'a b


The important part of the equivalence would be that DO value would 
be equivalent to DO reduce [:value], that it be equivalent to evaluating 
that value inline *in a block all by itself*. That would deal with 
the parameter problem, with making sure that set-words and set-paths 
trigger errors properly, it even would work with refinements and 
issues.

Thanks, Ladislav. Good examples!


The thing, I missed, was that REBOL has this extra internal data 
structure to hold symbols (words), I though, just the contexts was 
used for that. So comparing words (that are not bound to any context) 
are much faster than comparing strings in REBOL. I see different 
possibilities, depending on implementation. If a word is changed 
to the result from a hash calculation, then two different words might 
give the same result, right? It's unlikely, but it could happen. 
That's why map datastructures are combined with lists, when two different 
hash calculations give same result. The other possibility is, that 
words are changed to pointers pointing to their entry in the map 
(hash table). Do you know, what of the two, REBOL implement? In other 
words, could two different words be equal in REBOL?


About the strings, then it's possible to do kind of the same with 
hashing. Lua does that. If you have two different but identical strings 
(same string content) in Lua, they share the same memory area. Hashing 
is involved, and I guess, comparing string would be equal fast as 
comparing words, if REBOL did the same. (unless words are exchanged 
with the result from the hash calculation, but then two words might 
be equal)

could two different words be equal in REBOL?
 - in my opinion, that would be a bug

In R3, upper- and lowercase chars are equal, which leads to:

>> #"a" = #"A"
== true
>> #"a" > #"A" 
== true

Isn't that a mistake?

But how can something both be equal and larger than something else 
(using normal equal)? Think about it! Look at strings:

>> "a" = "A"
== true
>> "a" > "A" 
== false

(I wouldn't go for this solution for chars though.)

= isn't "normal equal", it's approximate equal. All four of the equivalences 
are "normal", for different circumstances.

Perhaps the relative comparison functions could be made to all be 
case-insensitive (for datatypes that have case defined as a concept), 
and have additional STRICT-* case-sensitive functions which would 
combine the functions and STRICT-NOT-EQUAL?.

The term "relative comparison hierarchy" may be better, since it 
wouldn't include NOT-EQUAL? and such.

AFAIK, R3 always has been faster or equal in the early tests I made, 
that's why I don't understand the current situation.

I hope, that we all agree, that, as opposed to other string syntaxes, 
there will be no escaping in heredoc, meaning, that the two strings 
below will be equal:

{^^}

#[[
^
]]

Oldes, exactly the use case to use case... 

case [
	a/x < b/x [-1]
	a/x > b/x [1]
	a/y < b/y [-1]
	a/y > b/y [1]
	'equal 0
]

We have find/only for this

a: [ [ 1 2 ] [ 3 4 ] [ 5 6 ]]
find/only a [ 3 4 ]


but what if we wanted to find [ 4 3 ] where we want [ 3 4 ] to be 
equal [ 4 3 ] ie. same set?

>> heapsort [5 1 2 4] :lesser?
== [1 2 4 5]

, while

>> heapsort [5 1 2 4] :lesser-or-equal?
** Script error: cannot compare none! with integer!
** Where: comp while heapify for heapsort
** Near: comp s/:child s/:start

, is that intended?

Ladislav, I corrected the issue with :less-or-equal?
And made some optimizations (I hope so).
On large serie

Steeve, my measurements suggest, that your previous version was a 
bit faster (is it caused by the fact, that you have to provide also 
for :lesser-or-equal?