World: r3wp

but, you did not take into account, that the spacing of 4.94065645841247e-324 
is not used

(by the implementation)

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 
?

Hm, this is not trivial! :-)

Yes, it can. If
random tt62
result in tt62 - 257

>> 1.0 - (tt62 - 257 / tt62)
== 1.11022302462516e-16

So the problem is there, just not as big as I first thought.

The first random function was:

tt62: to integer! 2 ** 62
r: func [x [decimal!]] [(random tt62) - 1 / tt62 * x]


and if (random tt62) - 1 result in tt62 - 257, the space between 
numbers are smaller than if (random tt62) - 1 result in 1. Hope I 
make sense.

yes. If the difference is detectable by a test, then we should change 
the implementation

I found some interesting observations in working with Random data 
recently.  I was mostly working with the RandomMilliondigit.bin file 
data that is used to test compression algorithms.  It exhibits a 
characteristic in that repetitious data is ascends in almost a 1-2 
ratio.

Additionally, the distribution of bits are tight.  Meaning that the 
distribution of 10, 01, 00, 10 bit sequences for example are very 
close to the same quantity.

For example, in set of data you might find how many occurences of 
3 '0 bit squences you have in the data.  Once you now the number 
of the occurences then for random data the 4 '0 bit sequences should 
be about half that and so on.

Cool, time! has been reimplemented.

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.

yes, it is possible to set it that way

(differs from the current behaviour)

are there other votes for the change?

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

differs from the current behaviour

 - The time! type is being rewritten right now because itts current 
 behavior is bad.

Equivalent? - it would use time zone math, even EQUAL? now uses time 
zone math:

>> equal? 7/7/2009/10:00 7/7/2009/10:00-02:00
== false

>> equal? 7/7/2009/10:00 7/7/2009/8:00-02:00
== true

(i.e. UTC is compared)

As long as no zone is equal? to zone of 0:00 I am happy.

no zone is actually 0:00 zone

>> 7/7/2009/10:00/0:0
== 7-Jul-2009/10:00

t/zone = none, but basically yeah

aha, did not notice, that there are actually two zones: zone = 0:00 
and zone = none

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.

Wait again, == also does case checking. Does EQUIVALENT? do case 
checking?

Equivalent?: ignores datatype differences, alias distinctions, character 
case differences

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

Then this seems like a good add, unless it is reserved for =?

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

t/zone = none - how did you get that?

Yeah. (Bad hand, bad keyboard day)

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

BTW, I should probably put the tests away from the main article, 
otherwise it is quite unmanageable, what do you think?

Oh, the t/zone is really d/zone - it's a date! thing, recently fixed.

Please moo their own page.

yes, but still, it is not none, but 0:00

moo -> move the tests to. Bad AltMe as well.

OK

You're right:
>> d: 12-Jan-2000
== 12-Jan-2000
>> d/zone
== none
>> d: 12-Jan-2000/1:00
== 12-Jan-2000/1:00
>> d/zone
== 0:00

Current build, don't know about after Carl's current changes.

d/zone  = none is related to the d/time = none, yes

("pure" date)

So apparently the time zone is never none, but the whole time in 
date! may be none.

this is discerned by Equivalent? already, otherwise it would not 
be transitive

Ladislav, check bug#1049 - I added a new comment. We need to discuss 
this.

this is already done by MOLD, so it is present

(I mean the marking)

...as well as collect-words, etc....