World: r3wp

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.

Wait for the proposed equivalency function changes in the next version.

Like:


>> (to-integer  #{3fef ffff ffff ffff}) < to-integer #{3ff0 0000 
0000 0000}
== true

Having a margin of error is standard operating procedure for IEEE754 
floating point numbers, because anything over 15 digits are subject 
to rounding errors inherent in the encoding.

That is why the 15-digit default.

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

If you can't count on differences in the greater-than-15-digit range 
to be accurate, why should you consider them for comparisons?

Well, I see no reason, why this return false, no matter of precision:


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

But maybe I need to think about it some more.

It's like the decimal-digits have internal consequences, it shouldn't 
have.

For instance:
>> 0.3 < (0.1 + 0.1 + 0.1)
== false
>> 0.3 <= (0.1 + 0.1 + 0.1)
== true


Those values differ in the greater-than-15-digits range due to encoding 
errors.

Those encoding errors are inherent in the IEEE754 format. The standard 
way to work around this is to not consider differences in the past-15-digits 
range. This is the case for all sorts of systems.

If you want exact comparisons, use money! ot integer! - decimal! 
is not appropriate.

Or you can wait for the next version, and have EQUIV?, ==, !== and 
=? do 17-digit comparisons, and the rest do the 15-digit comparisons 
that make values like 0.1 work.