World: r3wp

It will be native (inside the actions). Most of the silly stuff inside 
IDENTICAL? goes away if you are doing C code. The done lists can 
be more efficient too.

The lines to remove:
            a: head :a
            b: head :b

yes, but what about the search? that is O(n)

The done lists can be hashed on the pointer values.

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?)

Just mining it for the topological equivalence algorithm :)

if you look a bit further, you can see, that even to define what 
is cyclic can be ambiguous, there are two such detector functions 
in the text

All that matters to me is cyclic references after the referenced 
position - values before the position don't matter to anything but 
SAME?.

yes, looks fine for the comparison

same? is actually the simplest comparison, it is much easier to find 
whether two values are the same, than whether they are similar

btw, did you notice there is a deepcopy function? (the http://www.rebol.net/wiki/Identity#Making_a_deep_copy_of_a_.28possibly_cyclic.29_block)

Yes, but I haven't traced it yet.

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

to the other code: so, it looks, that it is difficult for you to 
test the actual implementation, i.e. the random x function, where 
x is decimal. No wonder, but I have and idea how to do that.

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

moreover, your random/seed now does not make any sense in case like 
this, you should use random/seed 0 or something like that to make 
sure everyone obtains the same result

Carl states, that time-zone precision was rised to 15 minutes. Is 
it any usefull? :-) http://www.rebol.net/r3blogs/0217.html

Any and all fixes to time would be good.

It helps us map to those few (but real) areas of the world whose 
timezone is +/-15 offset from a whole hour. That's useful to some!

Yeah, I'm not so much testing the actual random decimal function, 
but more the program logic of the implementation.

hi, renaming the EQUIVALENT? function to EQUIV? - Carl's wish

(the original name was probably too long)

anybody knowing how to rename the http://www.rebol.net/wiki/EQUIVALENT%3F_tests 
page?

OK, just found out how to do it, sorry for bothering

In CureCode ticket #870 Carl states: "Beginning in A68 PARSE/all 
is now the default when the rules are a block (not a simple string 
of delimiters). " - does it mean, that now parse is dependant upon 
the rules input? So when the input for rules is block, parse is switched 
to /all mode, while with string rule, it is not switched to /all? 
That will be confusing, no?

I would discard non /all mode completly ...

put it to R3 chat, Carl may honor your request

posted to R3/Parse thread on R3 Chat ...

I suppose the name change was inevitible given that noone could come 
up with a decent operator to associate with the function. Hopefully 
people will expand the name to "equivalent" in their heads and it 
will have the same psychological effect - the length of the word 
was the reason for its choice in the first place.

Is this decimal problem also found in latest release? (I'm currently 
using older OS X version.)


>> (to-decimal #{3fef ffff ffff ffff}) < to-decimal #{3ff0 0000 0000 
0000}
== false

It's also a problem in sort:

>> sort [1.0 0.9999999999999998]
== [1.0 0.9999999999999998]

The first one is the same in A68

The second one is:

>> sort [1.0 0.9999999999999998]
== [1.0 1.0]

What about

sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]

[1.0 1.0]

Try upping system/options/decimal-digits to 17.

noting that default is 15.

And the number of digits in your example is 16.

Setting it to 17 gives same wrong result here.

With 17:

>> sort [1.0 0.9999999999999998]
== [0.99999999999999978 1.0]

And what if you do:

sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]

>> sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]
== [0.99999999999999989 1.0]

>> sort reduce [1.0 to-decimal #{3fef ffff ffff ffff}]
== [0.99999999999999989 1.0]

And setting it to 17 and trying:


(to-decimal #{3fef ffff ffff ffff}) < to-decimal #{3ff0 0000 0000 
0000}

still false for that one

ok. Do you guys know, if there's a CureCode ticket about it?

If you use <= you get true. It could be within the margin of error.

I'm wondering, if it could have consequences in other functions/mezzanines.

The decimal-digits option is only used for display. All other comparisons 
use 15 digits.

I think, decimals should be treated as binary data and converted 
to integers, when doing comparison and the like.