AltME groups: search

yes but I don't think anyone new to REBOL  is going to expect 10,000 
dollar plus 1 to equal 11 dollars.

Are you meaning you want the worlds you host to auto-start?  If so, 
simply create a shortcut in your startup folder with the taget field 
equal to;

Anyway, I don't want to argue this, you should know about how to 
handle units. Everyone should know that 10 Metres x 10 Metres does 
not equal 100 Metres.

To Gregg,

The diff algorithm I am using ... 

2 blocks, one for reg-data-old (block1), the other for reg-data-new 
(block2).
data in these blocks are in the following format:
   [ key1 value1 key2 value2 key3 value3 ... ]
   where keyX and valueX are both strings. 
Example:

   [ "HKEY_LOCAL_MACHINE_SOFTWARE_ABC"  {"sid"=dword:00000001^/"tid"=dword:000000FF} 
   ... ]


I use "SORT/SKIP 2" to sort the 2 blocks. It's very fast, I guess 
that's because the original data are in order already. After sorting, 
I can comapre these two blocks with the "race" algorithm. 

The "race" algorithm is very simple ...

loop [
    if ... the key in block1 is equal to the key in block2 
    then ... check their values (different values mean modified) 

    if ... the key in block1 is less than the key in block2

    then ... the key in block1 is deleted-key. Move the key in block 
    1 to the next key.  

    if ... the key in block1 is greater than the key in block2

    then ... the key in block2 is added-key. Move the key in block 2 
    to the next key.  
] 


Well, my English is not very good. I hope you understand what I am 
saying here.

>> strict-equal? probe to-string join #{a4} #{68} probe to-string 
join #{a4} #{48}
¤h
¤H
== false

this is where objectivity is at loss.  they are equal and not depending 
on what you consider equal, or rather if:
- the evaluated human concept is equal (a space)

- the rebol value can be converted to from two types symbiotically.

- they obey a specified set of guidelines like (if converted to string 
both are equal)

- they must be strictly equal (of same type, but not the actually 
same instance)
- the same (actually two references to the same value)

If you just need to save large arrays of integers, you can use format 
used in AS3:
 The AS3 Integer can be encoded into between 1 and 5 bytes.

    *

      if the integer is between 0×00 and 0x7F then only one byte (representing 
      the integer)
    *
      if between 0×80 and 0x3FFF then 2 bytes :
          o
            (i & 0x7F) | 0×80
          o
            (i » 7)
    *
      if between 0×4000 and 0x1FFFFF then 3 bytes :
          o
            (i & 0x7F) | 0×80
          o
            (i » 7) | 0×80
          o
            (i » 14)
    *
      if between 0×200000 and 0xFFFFFFF then 4 bytes :
          o
            (i & 0x7F) | 0×80
          o
            (i » 7) | 0×80
          o
            (i » 14) | 0×80
          o
            (i » 21)
    *
      if more or equal than 0×10000000 :
          o
            (i & 0x7F) | 0×80
          o
            (i » 7) | 0×80
          o
            (i » 14) | 0×80
          o
            (i » 21) | 0×80
          o
            (i » 28)

Here's one way -- though it assumes (for simplicity) that the binary 
is a string of equal length in all keys:


data: reduce ["z" make object! [key: 1] "y" make object! [key: 2] 
"z" make object! [key: 2]]
sort/all/skip/compare  data 2 func [a b][
     return (join a/1 a/2/key) < (join b/1 b/2/key)
    ]
probe data

Started from console, and it should just halt. I get this wrong sometimes 
myself. It could be good to have an equal way of doing this, so please 
tell me, when you find a good way! Standards! (It should also work 
equally on all version of REBOL on all platforms.)

when doing a read/part http://www.somewhere.com500


does it really only read the first 500 bytes, or does the server 
deliver everything and REBOL just cuts it down to 500 bytes client 
side? it seems to take an equal amount of time to read 500 bytes 
and 100 kb.

x will never equal a/parent.

I investigating the deets, but you might get away with strict-equal? 
   res == false; need to test.

what is the difference again between strict-equal? and equal?

strict-equal? compares value and type, and then there is identical 
testing with =?   where

a: "abc"  b: "abc"     a =? b  is false   c: a   a =? c  is true 
(pretty much has to occupy the same ram)

that is what I thought btiffin - when you mentioned using strict-equal? 
you have me confused.  How did you see it being used in a true false 
function?

Instead of    if false? expression [ ]   you might get away with 
 if strict-equal? false expression [ ]   and skip writing the false? 
 func.

It relies on the FIND finding blocks based on whether they are the 
same, not equal. That means that the reference to the code block 
that is passed to INITIALLY can itself be used as a tag.

All you have to remember is that word! and lit-word! are different 
datatypes, so values of those different datatypes won't be equal.

Another question. Let's say I have a func .. xyz: func[msg] [print 
msg]

and I have a string "xyz this message" that I convert to a block 
 blk: [xyz "this message" ]

How can i set xyz in that block to equal my xyz function.. so that 
I can DO the block and end up with 
this message
 
?

i see but i'm just asking how it's possible, same? should check the 
inner address of the objects.

if they share the same block! of propertie values it should remain 
equal, no ?

but if the sort on the default data block is applied with a skip 
size equal to your span, then positions are not messed up, is that 
what you mean ?

but not if he's sorting data with a skip size equal to the span

Doc, the problem is that Paul never actually passes a lit-word to 
the function, so he can't test for strict-equal?. It just happens 
to work the way he wants for lit-words.

See doc - that is with the strict equal.

Paul, in your examples : as-lit-word? test is equal to : as-lit-word? 
1. Functions arguments are evaluated before the function is called 
 except if the functions arguments are defined as lit-word! in the 
specification block.

The implicit type convesion in evaluating #"a" = 97 is consistent 
with the help text :

>> ?
 =
USAGE
:
    value1 = value2
 

DESCRIPTION:

     Returns TRUE if the values are equal
. 
    = is an op value
.

ARGUMENTS:

     value1 -- (Type: any)

     value2 -- (Type: any)

Same can be said about ==:
>> "abc" == "ABC"
== false

It's the definition of the word "equal", that is a bit confusing.

I have sympathy for the opinion against coercion, if it is a real 
problem in real applications, but I also think, coercion can be good 
in many cases.


We have == (strict-equal?), and I think, it works as == (or =) found 
in many languages, and that is without coercion. And then we have 
=, that can be seen as a loose equal with coercion. I would like 
this coercion to be extended (if it makes sense), so these will give 
true:
1
 = 1
#"1" = 49
49
 = 49
a
 = "A"
a
 = 'a

1
 should not be equal to #"1", because this is true:
(first "1") = #"1"

(Just suggestions.)

What I'm after are very good arguments to have both equal? and strick-equal?. 
The less differences between them, the better argument to not have 
both. I think, both should be there, and equal? should have even 
more coercion than today. Maybe it even makes sense to take it further 
to include blocks? Should two series with the numbers 1, 2 and 3 
in them be equal?

123
 = [1 2 3]


Why not? Today we have to put to-string in front of the block to 
make them equal.

Let's look at this example. I have two words, iss and str, that represent 
some value, and they're some datatype. This is charasteristics of 
them:

>> series? iss
== true
>> series? str
== true
>> first iss
== #"a"
>> first str
== #"a"
>> length? iss
== 3
>> length? str
== 3
>> pick str 2
== #"b"
>> pick iss 2
== #"b"
>> str/3
== #"c"
>> iss/3
== #"c"

They seem quite alike. Are they equal?

>> str = iss
== false

Nope! Why not?

>> str
== "abc"
>> iss
== #abc


Again, I see little point in having both equal and strict-equal, 
when there's so little difference between them. If there were more 
differences between them, it would be good arguments to me for having 
both.

Issues and strings should be equal, I think, like integers and decimals 
can be equal, and numbers and chars can be equal.

Also I think, you can do exactly the same things with e.g. blocks 
and lists, but they're not equal:

>> [1 2 3] = make list! [1 2 3]
== false

(I totally agree, they shouldn't be strictly equal using ==.)

But if we didn't have strict-equal then how would we know when a 
variable is a pointer?

You don't check, if they point to the same mem area with strict-equal, 
you use same? (or =?) for that:

>> a: "abc"
== "abc"
>> b: "abc"
== "abc"
>> a == b
== true
>> a =? b
== false


So it's not obvious, they point to same memory address, just because 
a == check returns true.

There are bugs in strict-equal? in R2 as well.

Sorry, it is strict-not-equal? that has the bug:
>> strict-not-equal? 1 2
== false

STRICT-NOT-EQUAL? only checks types with integer! values. Use NOT 
STRICT-EQUAL? instead.

Actually, to make that a stable sort it should be greater-or-equal? 
instead.

Isn't something like this code already built-in in REBOL and I'm 
just missing it:

copy-to: func [series [series!] arg /local cpd d][
    cpd: make type? series 10
    foreach item series [
        either not-equal? arg item [insert tail cpd item][break]
    ]
    cpd
]

The optimization I really like is:

	if i = 1 [j: 2]

with:

	all [i = 1 j: 2]

when I'm reading code it seems to parse in my brain better:


 "if i equals 1 ... then ... j becomes equal to 2" vs "i equals 1? 
 j becomes equal to 2"

blocks seem to introduce a mental "pause" when I read code.

The char! datatype has many similarities to numbers. The following 
is from R3 and looks strange to me:

>> var - 32 = var
== true


What variable is equal to it's original value, even if you subtract 
32 from it?

>> var: #"a"
== #"a"
>> var - 32 = var
== true


A bit strange. I would prefer SWITCH to distinguish between #"a" 
and #"A".

Izkata: /strict could also striclty equal to numbers to give an alternative 
to :

>> number: 1

== 1
>> switch number [1 [print 1] 1.0 [print 1.0]]

1

>> number: 1.0

== 1.0

>> switch number [1 [print 1] 1.0 [print 1.0]]

1

Gregg, are you really sure, you mean this? As I see it, the life 
would be much easier, if "a" equals "A", but #"a" didn't equal #"A". 
As it is now, it's really problematic testing for different characters 
in a string using SWITCH. Cases where "a" and "A" should be handled 
as the same is ok, but cases where they should be different is the 
problem. If #"a" was made to not be the same as #"A", then both situations 
could be coped with easily.

At the moment Switch is consistent with Equal?. Surely, it would 
be better to retain that consistency and have a /strict refinement 
for switch which perfomed consistently with strict-equal? ?

Peter, the equal thing is correct for R3, not R2, which we still 
get updates for now and then.

In other words, SWITCH is not consistent with EQUAL in R2, when talking 
the char! datatype.

First, it should be consistent between R2 and R3 if at all possible. 
For SWITCH, I think the solution is to add a refinement if people 
think it's needed. If the new native SWITCH is still based on SELECT, 
adding a /CASE refinement shouldn't be hard.


For the more general case of char case-sensitivity, we have ==/strict-equal?

I agree with Geomol here.


many people see chars as a subsitute for string, even I once saw 
it like that, but I have come to realize that they shouldn't be.

#"A" should not be equal to #"a".

the specific is that 

a: 'z      and     a: to-lit-word 'z

are not equal expressions.

so why should evaluating a also evaluate z in the second form.

%
 is the variable begin/end tag. ie:
	C:\> set directory=c:\windows
	C:\> dir %directory%


But in batch file, it's also the begin tag for a "number" variable 
equal to the n'th parameter of the script. %1 for first param, %2 
for second... ie:
	C:\> type mybatch.bat
	dir %1

	C:\> mybatch.bat c:\windows

50% + 10% should be 60%, but 50% + 10 should equal 10 + 50% no matter 
what one decides otherwise.

E.g. this modification works regardless of auto-adjustment: (i.e. 
even in R3)

past?: func [
	"Returns TRUE if a series is past its tail."
	series [series! gob! port!]
] [
	and~ greater-or-equal? index? :series index? tail :series
	    not same? :series tail :series
]

I've been looking at %view-edit.r recently (and Romano's excellent 
http://www.rebol.it/~romano/edit-text-undo.txt), and have the following 
three code change suggestions:


1) Allow Shift-Tab to cycle back through the first / last pane objects 
(as Tab does):

	back-field: func [face /local item][
		all	[
			item: find face/parent-face/pane face

   any [if head? item [item: tail item] true] ; new line added here
			while [face <> first item: back item][
			...

2) Implement a new function to hilight the current word.

	current-word: function [str] [s ns] [
		set [s] word-limits
		s: any [all [s: find/reverse str s next s] head str]
		set [ns] word-limits
		ns: any [find str ns tail str]
		;	hilight word
		hilight-text s ns
		show view*/focal-face
	]


3) Refactor the engage / down action to allow double-click selection 
of a word (something I use all the time in almost every editor I 
use).

Current code:

	down [
		either not-equal? face view*/focal-face [
			focus face
			view*/caret: offset-to-caret face event/offset
		][
			view*/highlight-start:
			view*/highlight-end: none
			view*/caret: offset-to-caret face event/offset
		]
		show face
	]

Proposed change:

	down [
		either event/double-click [
			current-word view*/caret
		][
			either face <> view*/focal-face [focus face] [unlight-text]
			view*/caret: offset-to-caret face event/offset
			show face
		]
	]

Comments?

view/new layout [
	the-field: field feel [

		;;;; 
		engage: func [face act event][
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]
				key [
					edit-text face event get in face 'action
				]
			]
		]
		;;;;

	]
	new-field: field
]
focus the-field
do-events

view/new layout [
	the-field: field feel [
		engage: func [face act event] bind bind [
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]
				key [
					edit-text face event get in face 'action
				]
			]
		] in ctx-text 'self in system/view 'self 
	]
	new-field: field
]
focus the-field
do-events

0.0.15 uploaded

Changes:
      New: Updated documentation with images
      New: DATA can now also be a single block of values
      Fix: IN-COLS is no longer mandatory
      Fix: MAIN-COL is no longer mandatory
      New: Default WIDTHS now a fraction value.
      New: Fractional widths of the list width as decimals
      Fix: List size calculation optimizations

      Fix: Scroller width is now always equal to the corner reset button 
      width
      New: SCR-WIDTH lets you set the scroller width
      Fix: AGG is no longer a requirement
      New: CLEAR to quickly clear the list

The files have moved again:
    http://www.hmkdesign.dk/rebol/list-view/list-view.r

    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view/list-view.html

That's the way how the twips works 1px = 20twips so 1.2px = 24twips 
- the scaling is done on the draw engine side so you don't need to 
scale it yourself. In my dialect i just have directive 'units twips' 
and then the interpreter know that 24x24 is equal to 1.2x.1.2  --- 
if I'm not using twips all values are multiplied by 20 and rounded 
- that's the way how it's in Flash and in my Rebol/Flash dialect

How to change part o f a color in gradient?
F.ex.

	at 535x100 box teal 30x315 effect [
		draw [
			fill-pen linear 0x0 0 315 90 1 1 red yellow green
			box 0x0 30x315
		]
	]


Now I have each color equal, but how to make so that f.ex. green 
is ~50%, Yellow ~30% and red ~20% of box?

REBOL []

stylize/master [
	myfield: field with [
           feel: make feel [
		engage: func [face act event][
			switch act [
            	down [

                  either equal? face focal-face [unlight-text] [focus/no-show face]
                		caret: offset-to-caret face event/offset
                		show face
            	]
		        over [

                  if not-equal? caret offset-to-caret face event/offset [

                   if not highlight-start [highlight-start: caret]

                      highlight-end: caret: offset-to-caret face event/offset
                    		show face
                		]
        		]
            	key [
						if event <> newline [
						         edit-text face event get in face 'action
                        ]
				]
        	]
    	]

	]
]
];end of stylize?
halt

that was wrong, sorry:

REBOL []

stylize/master [
	myfield: field feel [
		engage: func [face act event][
			switch act [
            	down [

                  either equal? face focal-face [unlight-text] [focus/no-show face]
                		caret: offset-to-caret face event/offset
                		show face
            	]
		over [

                  if not-equal? caret offset-to-caret face event/offset [

                   if not highlight-start [highlight-start: caret]

                      highlight-end: caret: offset-to-caret face event/offset
                    		show face
                		]
        	]
            	key [edit-text face event get in face 'action]

                        ]
				
        	]
    	]


];end of stylize?


view layout [f1: field f2: myfield button "End" [quit]]

view layout [
	field feel [
		engage: func [face act event] bind bind [
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]

    key [if event/key <> #"^M" [edit-text face event get in face 'action]]
			]		
		] system/view ctx-text
	]
]

O'k found myself - selection is in face/picked and they should be 
equal of elements in face/data:
F.ex:
face/data: [ "peas" "apples" ]
face/picked: [ "apples"]
the above statement shows selection in face after "show face" 
face/picked: [ "apple" ] 

the above statement do not show any selected row after "show face"

yes but the corner is not *ON* the line, its equal to the major and 
minor axis of the elipse.

either you use AGG for aliased fonts, or you increase image size 
so its equal to the dpi you want to print.

hum (i have to be a little bit rude), i just read your response on 
rebol.net about the opportunity to turn or not return into a more 
genralized EMIT functions (as i proposedl).

I will not discuss about the difficulty to implement that idea (i 
don't have the sources). But what i can say, is that a COLLECT behaviour 
will be more usefull than all return break/return stuffs u posted.

Have you inspected scripts in Rebol.org recently ? If u had done, 
you would see that many coders use parsing  to collect data.

The problem Graham, is that  when i read your arguments, i have the 
unpleasant impression that your are alone to decide if an idea is 
bad or good.  

The narrow minded sentence " Incorporating COLLECT and KEEP into 
PARSE is both unnecessary and doesn't help at all for building hierarchical 
structures" suggest that you had not  widely used parse in your code. 
 I don't think you are the best  people here to made these choices. 
Many script contributors on Rebol.org have made some masterfull piece 
using parse (not you).

So when you reject an idea you should be more sensitive with this 
simple fact: many poeple  here  have an equal or better  experience 
whit  parsing than you.

ok i try again a new proposal:
ALL [rule1 | rule2 | rule3] 

each rule must be fullfiled one time but in any order (combinatory).

it's equal to [[rule1 rule2 rule3] | [rule1 rule2 ruel3] | [rule2 
rule1 rule3] etc...]

tab-panel: will investigate
min-size: from the display users guide:

2.1.2 Min-Size

Specify a minimum OS window resize size.

display/min-size "Example" [
    tight
    text 80 blue "Some text" #W
    return
    box 80x40 #WH
] 400x400

Note


The min-size limit will only be enforced upon a window resize, and 
the size is inclusive of an OS specific number of border / title 
pixels. Also note that if any widgets are resizeable (#H and #W) 
and min-size has not been specified then RebGUI will assign a default 
value equal to the initial window size.


table: Already noted by Graham (arrow does not share label feel) 
- will add to list

How is the svn related to get-rebgui?

 The SVN is for developers / experienced REBOLers ... it is used to 
 manage individual widget source files. %get-rebgui.r obtains a pre-built 
 distribution (including a merged %rebgui.r, %tour.r, images and demo 
 scripts). It is targeted at 'end users' who don't want to use SVN.

%tour.r is missing

 I want to add it *without* having to also add sample icon images 
 to the SVN. I'll probably just 'inline' the images so it's all in 
 one big file.


min-size: read this very carefully: http://www.dobeash.com/RebGUI/display.html#section-2.1.2


The Note says it all: "The min-size limit will only be enforced upon 
a window resize, and the size is inclusive of an OS specific number 
of border / title pixels. Also note that if any widgets are resizeable 
(#H and #W) and min-size has not been specified then RebGUI will 
assign a default value equal to the initial window size."

Hi Graham, in my example-2 the the right-most text-lists keep their 
widths, and the lower text-lists keep their height, and the upper 
left text-list is maximized to fill the size of the window.
I would like to have equal sizes for all text-lists.

Ingo:


is there a reason, that display opens the windows, but does not start 
do-events?

 ... we can't assume the "first" window automatically needs to start 
 the event loop. Perhaps the display is being assigned to a word and 
 cached for later use? Or the display is done early in the script 
 for lots of subsequent initialization and *then* needs to fire up 
 the event loop. I personally like having to code it explicitly as 
 it then stands out - "We are starting the event loop HERE".

Is it possible to get the window size?
 ... display [button do [ws: face/size]]

Is it possible to set an own resizer function?

 ... No, you'd have to change a lot of code to implement your own.

I would like to have equal sizes for all text-lists.

 The RebGUI resizing model is pretty basic, it supports one resizeable 
 widget in each axis (horizonal and vertical) with any number of offset 
 adjustments (the #XY directives). More advanced schemes (such as 
 proportional or percentage based) are possible, but significantly 
 harder to implement (and require size/state information to be retained).

Yes. Technical difference between it and on-key is that on-key is 
called prior to keystroke processing, whereas on-edit is only called 
if the keystroke actually changed the text (including a change in 
capitalization ... i.e. it does a strict-not-equal? comparison).

Hi. Is there a way to call a method (an object function) programmaticaly 
? ie supposed I've got a Car object with a function "drive-to" inside. 
Now, I've got a string "action" equal  to "drive-to". I want to do 
Car/action but that does not work (I can understand why), but is 
there any workaround ?

Hi. Is there a build-in function do do something like this : given 
the number 5 and the string "abc"  construct the string "abcabcabcabcabc" 
(equal 5 times "abc")?

You asked how to make a random number between e.g. pi and -pi. There 
are a number of ULPs (Unit in the Last Place) between those two numbers. 
For 64 bit decimals, it's a large number. The possible decimals in 
computer arithmetic lie closer together around zero than for large 
numbers. If you had a routine, that would give you any possible 64 
bit decimal number between pi and -pi with equal probability, then 
you would get a lot more numbers close to zero than close to either 
pi or -pi. The distribution wouldn't be flat (as you would expect).


It's much better to choose, how many different values between pi 
and -pi, you need, and then make a random integer of that number, 
and do some calc to get the result between pi and -pi.

I hope, it makes sense.

BrianH or Steve,   I have seen some example code showing the following:

x:	copy []
y:	[]

These are both equal right,  Why do one over the other?

They are not equal. The first makes a copy, the second references 
the original.

if not = unless

also perhaps:

if none? _first [_first: current] = any [_first _first: current]

not equal? = not-equal?

Didn't check if there are some mezzanines in there, though.

= (or equal?) is not exact. Use == (strict-equal?)

>> (1.48297457491612E-2 + 0.985170254250839) == 1.0
== false

I think we agree it is "useful".  But, for example, I would never 
take ANY fact offered on Wikipedia and assume it is "true" without 
my own separate confirmation.  Nor would i use Wikipedia + some other 
source "together" to equal truth.  In other words, I would use Wikipedia 
to learn "about" a fact, and then judge a seprate source on its own.

Nor would i use Wikipedia + some other source 

together" to equal truth." - well, I learned better from my experience. 
I was suggested the Standford encyclopedia as a reliable source on 
the problem I wanted to solve and found out that WP was corrected 
one point I wanted to find.

kg#123 and kg$123 sound equal to me. It is just that the datatype 
is called money! Dunno if english unit! term would be more descriptive/general 
...

So 10 would equal ten blocks read?

New operator !== for STRICT-NOT-EQUAL? - that was the last comparison 
action without an operator :)

So SAME? is less strict than STRICT-EQUAL? for words?

but, certainly not "completely less strict":

>> same? 'a use [a] ['a]
== false

>> strict-equal? 'a use [a] ['a]
== true

if we want the hierarchy to be linearly ordered by fineness, then 
the equality should compare just spelling of words, the second one 
- finer and non-existent yet, should compare spelling and binding, 
the third one should compare spelling + binding + datatype (can be 
strict-equal?), the fourth one is not that necessary in this case

I meant the one he labeled "the bottom level", the non-transitive 
one  ;)

I'll call "the bottom level" level 1, then increase to 4, for now. 
 Generally I only use EQUAL? in R2, which appears to me to be level 
2 (although you named it level 1?), but can see why the stricter 
levels 3 and 4 are helpful - I just don't see where level 1 can be 
used right now.


As far as naming goes, my only question is the need for negatives. 
 Why isn't NOT sufficient? ("not equal?" rather than "not-equal?", 
etc)


I forget MAKE can be used with things other than object!, I use it 
that way so rarely.  So yeah, /deep doesn't make sense now that I 
think about it   =P

You need a NOT-EQUAL? action so you can have a != operator. Every 
op! maps to an action!, no exceptions.

Domain of EQUAL? EQUIVALENT? STRICT-EQUAL? and SAME?: currently they 
are declared to accept all values except for #[unset!] Any proposals 
for change?

There is a lot of correct code that would assume that
>>greater-or-equal? length? head b index? b

If this is ever not the case and I try to retrieve a value from that 
reference before that condition is true again, that is a serious 
error. If you fill in the missing data before you attempt to retrieve 
anything, not an error.

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

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?

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

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)

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

>> two**62 / two**53+1
== 512.0

So two**53+1 * 512 should equal two**62, but it doesn't:

>> two**62
== 4611686018427387904
>> two**53+1 * 512
== 4611686018427388416

Why is that?

After you do:

d: d // two**53+1


Are we sure, the new d is even distributed? That every value, d can 
now take, is equal possible?

If all possible values of d is equal possible, and d now can have 
values from 0 to two**53, then

d / two**53

will return values from 0.0 to 1.0 both inclusive, and 

d / two**53 * x

will return values from 0.0 to x both inclusive. Right?

r-uni surely differs from r when X is equal to 1.0