World: r3wp

sorry, I mean poke block 4 index

Ladislav, my point was that if bounds matter, INDEX? *not* generating 
an error (or changing its results) for an out-of-bounds index *is 
itself an error*. If bounds don't matter (except apparently for POKE), 
then INDEX? not changing its behavior is fine.

aha, so you examined the possibility to change the INDEX? behaviour 
as well

my experience tells: it is better to be able to find out what the 
value of INDEX actually is (even for debugging), than to obtain an 
error, which does not tell me where I actually am

Yeah. However, consistently not caring about out-of-bounds on read 
seems more useful. We only care on write.

(that was in answer to your last message)

(AltME is slow for me today)

henrik:  the neutral? is very usefull, python uses that as the false 
values.


when everything is coded using this it simplifies a lot of code, 
even more than using none.

I have often wondered what the name for the function would be.... 
'NEUTRAL?  is not bad!

(altme is fast here. (very))

I prefer REBOL's false/none treatment to Python's, but that NEUTRAL? 
sounds good, especially if it also checked for unset values, and 
SERIES? instead of BLOCK?.

its just different allows different optimisation of conditionals. 
 neutral? can be very usefull, especially for GUI handling code... 
where you usually don't care for the type, but only if a value is 
meaningfull.

my name for the function was:   meaningfull?

I have not thought it through that much, other than figuring there 
would have to be a way to shorten that code to one step. I have compiled 
a list of neutral values for all types, that are capable of producing 
neutral values. Some can't, and I wonder what the response to NEUTRAL? 
would be there.

the lack of datatype screening might be a problem.

It could take a datatype/typeset parameter (probably the first parameter 
of two).

Internally you could even convert the datatype! to a typeset! and 
use FIND; since typesets are immediate there would be no overhead.

why should be this 
>> equal? b []
== true
but 
>> equal?  [] b
** Script error: out of range or past end
** Where: equal?
** Near: equal? [] b


equal? should just compare the two params, but not test if they are 
in in their own limits.


As I understand this, blocks are containers and empty containers 
are equal from the outside.
Even errors should be equal.)

seems, that Carl agrees with you

btw - as for 'arrays - will there be any change in R3? I never use 
them, as I worry they are slow (mezzanine). Now with vectors, blocks 
and arrays - do we have fast multidimensional arrays and vectors?

It is possible that vectors will get multidimensional addressing 
- it is sort-of planned to do so, but nothing concrete yet.

I don't understand: "I never use them, as I worry they are slow (mezzanine)."

REBOL doesn't really have multidimensional arrays. There is an ARRAY 
function that creates nested blocks (which is as close as C gets 
to multidimentional arrays too), but once created they aren't mezzanine, 
they're a data structure.

Once the data structure is in memory, it doesn't matter whether it 
was created with a mezzanine or a native - all that matters is what 
kind of data structure it is. The nested block style is better for 
some things (data structure manipulation, flexibility) but worse 
at others (vector math). You make your tradeoffs. At least in R3 
you have a choice :)

If I understand it correctly, Carl is leaving for vacation in France 
at the end of the week. So - what last minute fixes do we request, 
before Carl vanishes for 2 or so weeks? :-)

Nothing. Better let him finish up what he was doing.

Do you think fixing another 20 tickets, or releasing plugins finally? 
:-)

Well, summer is going to be a slow time anyway, for many of us ...

If necessary, put off releasing the plugins until after the vacation, 
in case perspective is needed :)

Peter once ( Rambo#3518 ) objected against some things being inequal. 
I could use more opinions on this.

this is a test that succeeds in R2 as well as in R3; but, is it really 
supposed to?

		a-value: first ['a/b]
		parse :a-value [b-value:]
		not equal? :a-value :b-value

(it is related to the Rambo#3518 ticket)

I like the idea of non-datatype-specific EQUAL? considering datatypes 
in the any-string! family to be equal to each other, and also the 
any-block!, any-word! and number! families. I'm a little wary of 
the potential breakage, though have no idea of the scale of it. Is 
anyone aware of any code that wouuld be broken if EQUAL?, =, NOT-EQUAL?, 
<> and != changed in this way?

;This is an example by Geomol:
d: to-decimal to-binary 1023
blk: []
insert/dup blk 0 1024
random/seed now
loop 1000000 [
i: to-integer to-binary random d
blk/(i + 1): blk/(i + 1) + 1
]
print [blk/1 blk/512 blk/1024]

showing, that my "original" implementation of the uniform deviates 
actually generated both endpoints of the specified interval: the 
0.0 as well as the given value, but both with the frequency equal 
to the half of the frequency of any interior value

it has been corrected (ticket #1027) yesterday, but Geomol seems 
to dislike the fact, that the correction excluded the given value. 
Anybody wanting to express their preferences?

I find, the first version, with both endpoints (0.0 and the input 
value) as possible output with half frequency than other possible 
values in between, gives most sense. I think of a number line going 
from 0.0 to the given value, and a random number is picked on the 
line.

well, for some applications (Fourier analysis) it makes the most 
sense that way

just for the record: a variant yielding all values in the interval 
including the endpoints with equal frequency is possible too (just 
the generating formula is a bit different)

RANDOM is a distribution. Getting random integers, the mean value 
is well defined as:

(max + 1) / 2

So e.g.

random 10

will give a mean of 5.5. What is the mean of

random 10.0
or
random 100.0

5.0 and 50.0 (or, do you mean, it is only "roughly" 5.0 and 10.0?)

Ladislav: I reported bug #3518 in Rambo mainly because the behaviour 
of the '= function is not consistent. My thinking was if 1 = 1.0 
why doesn't  #"a" = "a"?


It appears that the '= function acts as the '== function unless the 
types are number!. 


I have come to accept that Rebol has been designed pragmatically 
and, understandably, may be inconsistent at times. I thing this makes 
the need for accurate documentation essential. I would hope that 
the function help for = can be changed to accurately reflect the 
functions behaviour.

actually, my task now is to define the desired results of such comparisons 
for R3, (which may serve as documentation too)

The R2 behaviour has the advantage that it is easy to define and 
understand (especially if the function helpext was improved). If 
other options are to be considered, defining the desired results 
will be more difficult. No wonder  you ar taking this on.

I believe that there needs to be some restriction on the datatypes 
on which the '= function will work. It seems to make no sense to 
comparer a URL! with an email! (Unless you define a URL! to be equla 
to  an email! if they refer to the same ip address or domain name. 
Perhaps that's something for same?).


It's harder to say whether an issue! can be equal to a binary! but 
waht about an integer! with a binary!?

I WANT PLUGINS !!!!!    :-)

wouldn't it be cool to load a rebol instance as a plugin within rebol? 
 :-)

this could be the basis for an orthogonal REBOL kernel  :-)

Peter, are you sure you would never want to compare an email with 
a url?
What about urls like this?
http://some.dom/submit?email=[somebody-:-somewhere-:-net]


I might want to see if a given email can be found in the query string.

Ladislav, your "parsing a lit-path" example above looks ok to me 
for the proposed ALIKE?/SIMILAR? operator, and EQUAL? if it's been 
decided that EQUAL? remains just as ALIKE?/SIMILAR?, but not ok if 
EQUAL? is refitted to name its purpose more accurately (ie. EQUAL? 
becomes more strict).

Peter, in response to the suggestions in your last message:

- issue! = binary! : not good, at least in R3. Perhaps issue! = to-hex 
binary!

- integer! = binary! : not good, at least in R3. Use integer! = to-integer 
binary!


Actually, anything-but-binary! = binary! is a bad idea in R3, since 
encodings aren't assumed. The TO whatever conversion actions are 
good for establishing what you intend the binary! to mean though, 
especially since extra bytes are ignored - this allows binary streams.

Anton, we decided that making EQUAL? more worthy of its name would 
break too much code that depends on it being loose. Oh well :(