AltME groups: search

After that the xor with this different signed number get rid of the 
sign. 

Another little thing is the adding of the count/sequence number is 
different when added to a positive/negative number.

Getting the exact same result is important to me. While this version 
is good enough to use as random for throwing dice in a game of Yahtzee, 
distribution of randoms in longer term could be more predictable 
than with the "official" version, which would be a bad thing when 
used in encrypting.

I'm still working on figuring out the grid walking function... nice 
trick using xor and direction bits btw.

Thanks, when I did the trick in my Java applet I had never expected 
to use XOR at all ever. In Java I had an field of 10by10. I'll explain 
a little. Starting top left having an initial direction south start 
on the first field of the grid. determine the next direction to go 
then step and repeat until you step of the board stap=step r row, 
k for column (kolom) so stapr or stapk will be 0 or 9. then you are 
on the other end of the board. the values along the board is a series 
of 32 elements going clockwise around the board. Go to the next field 
clockwise when right your init direction is west etc.

find/reverse and find/last are somewhat identical but not from the 
same point of start. So you have to use one XOR the other.

Tilde is an option. There are three function in REBOL using that 
char, the function variations of and, or and xor. I call those and', 
or' and xor' in World, so that's a possibility in R3, if people wants.

And then tilde can be used in URLs, like:

>> type? url://~a
== url!


I can't judge, if that's a problem, if tilde should be used for comments 
too.

Gregg already mentioned XOR, I'll repeat: why not XOR?

>> #{FFFFFF} xor #{EEEEEE}
== #{111111}

Gregg and Andreas: 'xor seems to work, for the most part.  I have 
to do some more testing to know for sure.

R2 can use strings in AND, OR and XOR, like binary!, but they're 
not right aligned.

do you know XOR based Kademlia? http://citeseer.ist.psu.edu/529075.html

Mozilla Firefox will use bsdiff and bspatch for software updates. 
http://www.daemonology.net/bsdiff/, it remains me of xor based patching 
Gabriele came up with in the past. I wonder if similar aproach is 
still possible for Rebol products?

#3700: great! still doesn't work on images, but works fine with binary! 
and string!

some issues with string! usage in 'and 'xor 'or : 

1) string! op string! -> binary!, should returns a string! instead

2) a) string! op binary! -> error!, a) binary! op string! -> error! 
, 
should be allowed and do the same than:

a) string! op as-string binary! -> string! , b) binary! op as-binary 
string! -> binary!

Oops, talked a little too fast. Testing all datatypes combinations 
for 'and, 'xor, 'or, 

[ binary! | string! ] op [ logic! | number! | char! | tuple! ]  -> 
crash.

well, I hope so - it's the fundamental brick ;) but it's not intuitive, 
usage exemple (depends of port access mode...): 

crc: -1 while [not empty? data] [ctx-crc-32/update-crc data crc data: 
copy/part source length] crc: crc xor -1

The infix operators in REBOL can be seen with:
>> ? op!

It's a special corner of REBOL, as I see it. And I don't feel a big 
need to be able to make my own infix operators. There is a funny 
thing with the and, or and xor operators. They have twin and~, or~ 
and xor~ actions. The actions is used like: <action> <value1> <value2>, 
but operators can be used the same way, so the action counterparts 
seem to be irrelevant. Examples:
>> 3 and 9
>> and 3 9
>> and~ 3 9

Why do we have and~, or~ and xor~ made?

One can overload 'and~ 'xor~ 'or~ but should not overload 'and 'xor 
'or.

With form~ we know they are only used in <action> <value1> <value2>, 
and are safe to change.

>> index? find (as-binary a) xor as-binary b complement charset "^(00)"
== 7

I think I found some errors on the tuple math with rebol. This results 
don't make any sense to me. Does anyone agree that these are bugs?

>> 1.2.3 or -253
== 0.0.0
>> 1.2.3 and -253
== 1.2.3
>> 1.2.3 xor -253
== 0.0.0
>> 1.2.3 xor 512
== 255.255.255
>> 1.2.3 or 512
== 255.255.255
>> 1.2.3 and 512
== 0.0.0

It also seems the operator have inconsitent behaviour like this.

>> 1.2.3 and -1
== 1.2.3
>> 1.2.3 and -2
== 0.2.2
>> 1.2.3 and -3
== 1.0.1
>> 1.2.3 or -1
== 0.0.0
>> 1.2.3 or -2
== 0.0.0
>> 1.2.3 or -3
== 0.0.0
>> 1.2.3 xor -1
== 0.0.0
>> 1.2.3 xor -2
== 0.0.0
>> 1.2.3 xor -3
== 0.0.0

AND behaves differently than OR and XOR regarding on how they treat 
negative numbers. AND is taking into account as many bits as possible, 
while OR and XOR are just returning a tuple of zeros.

I agree. If it works with 'and', one would expect it to work with 
'or' and 'xor' too.

Not sure the best forum to put this on (to where Carl will see it). 
Are there plans in the future for actual bit operations besides and/or/xor? 
RIght now, bit shifting, rotating, etc. are extremely painful (and 
slow compared to what they should be) to do.

you mean like an xor type thing?

I had just found something via  search it looked like Carl was question 
about it and answered something along the lines of XOR.  Not sure 
if the function has evolved since then or not.

well, the safety of XOR is the safety of the passphrase. if it is 
random and same length as data, then it's the safest possible. :)

decimal unfortunately wont work without large slowdowns as I need 
to do AND/XOR/OR operations on the result

another option:


math-words: [+ - * / ** = == =? < <= > >= and or xor square-root 
negate]
math-words: use math-words reduce [math-words]
foreach word math-words [set word get in system word]
etc.

Also, I am not seeing the always-down effect you report.
   round/to $.125 .001
   == $0.13    ;; correctly rounded up


Round did go through a couple of development stages. Perhaps your 
version of REBOL has an outdated one. This is the source from the 
version I am using:

round: func [

    {Returns the nearest integer. Halves round up (away from zero) by 
    default
.}
    [catch]
    n [number! money! time!] "The value to round"
    /even "Halves round toward even results"

    /down {Round toward zero, ignoring discarded digits. (truncate)}
    /half-down "Halves round toward zero"
    /floor "Round in negative direction"
    /ceiling "Round in positive direction"
    /half-ceiling "Halves round in positive direction"
    /to "Return the nearest multiple of the scale parameter"
    scale [number! money! time!] "Must be a non-zero value"
    /local m
][
    throw-on-error [
        scale: abs any [scale 1]
        any [number? n scale: make n scale]
        make scale either any [even half-ceiling] [
            m: 0.5 * scale + n
            any [
                all [
                    m = m: m - mod m scale
                    even
                    positive? m - n
                    m - mod m scale + scale
                ]
                m
            ]
        ] [
            any [
                floor
                ceiling

                (ceiling: (found? half-down) xor negative? n down)
                n: add n scale * pick [-0.5 0.5] ceiling
            ]

            either ceiling [n + mod negate n scale] [n - mod n scale]
        ]
    ]
]

Paul, you have answered Henrik's question: make logic! works like 
C code, returning true when C would. TRUE? returns true when REBOL 
would treat it as true, not C. TRUE? is useful for AND, OR and XOR 
as well.

Yes, from a logical perspective ALTER behaves like XOR, where often 
one only really needs an equivalent of OR.

I recomend to use compressed bitmap EWAH scheme, in worst case tradeof 
is one 32bit word, in sparse bitmap it will save huge amount of space, 
AND,OR,XOR algorithms described for those bitmaps, usually used (but 
not restricted to) as DB bitmap index

Convert to integers (through tuple then binary) and do bitwise operations.
>> ip: to-tuple "10.10.10.10"
== 10.10.10.10
>> ip-as-integer: to-integer to-binary to-tuple "10.10.10.10"
== 168430090
>> set [mask-ip mask-range] parse "10.10.10.0/24" "/"
== ["10.10.10.0" "24"]
>> mask-ip: to-tuple mask-ip
== 10.10.10.0
>> mask-range: to-integer mask-range
== 24

>> mask-integer: (to-integer to-binary mask-ip) and (-1 xor (to-integer 
2 ** (32 - mask-range)) - 1)
== 168430080
>> mask-integer = (ip-as-integer and mask-integer)
== true

That process can be converted to the algorithm for your function:

in-ip-range?: funct [ip-fw ip-sq] [
    ; Convert ip to integer
    ip-as-integer: to-integer to-binary to-tuple ip-fw
    ; Convert mask to tuple and range integer
    set [mask-ip mask-range] parse ip-sq "/"
    mask-ip: to-tuple mask-ip
    mask-range: to-integer mask-range
    ; Calculate mask as integer

    mask-integer: (to-integer to-binary mask-ip) and (-1 xor (to-integer 
    2 ** (32 - mask-range)) - 1)
    ; Is ip within mask?
    mask-integer = (ip-as-integer and mask-integer)
]

>> (-1 xor (to-integer 2 ** (32 - mask-range)) - 1)
same thing than:
>>shift  -1 mask-range

See that weird one :)


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple skip to-binary (shift -1 32 - bits) 4
    mask and address xor network = .0.
]

rather optimized...


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple to-binary shift -1 64 - bits
    mask and address xor network = .0.
]

Because it was for R3 only, try this for R2:


cidr-match?: func [address [tuple!] network [tuple!] bits [integer!]] 
[

    address xor network and (to-tuple debase/base to-hex shift/left -1 
    32 - bits 16) = .0.
]

Don't know if it's faster than Andreas's, though

When trying to code D.J.Bernstein hashing function: forall key [hash: 
hash * 33 xor first key] I found that this simple notation is faster 
than traditional C like: forall key [hash: xor~ add shift hash 5 
hash first key]. (Note for real use it is necessary to shrink hash 
to 4 bytes.) seems shift and additioin is not faster than multiplication 
under Rebol?

maybe this is better description:

The password is saved (in user.password) by using the PASSWORD() 
function in
  mysql.


  This is .c file because it's used in libmysqlclient, which is entirely 
  in C.
  (we need it to be portable to a variety of systems).
  Example:
    update user set password=PASSWORD("hello") where user="test"
  This saves a hashed number as a string in the password field.

  The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

maybe this is better description:

The password is saved (in user.password) by using the PASSWORD() 
function in
  mysql.


  This is .c file because it's used in libmysqlclient, which is entirely 
  in C.
  (we need it to be portable to a variety of systems).
  Example:
    update user set password=PASSWORD("hello") where user="test"
  This saves a hashed number as a string in the password field.

  The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

I implemented scramble-long function as follows:

scramble-long: func [pass port][
     hash-stage1: checksum/method port/locals/long-seed 'sha1
     hash-stage2: checksum/method hash-stage1 'sha1

     to-string xor hash-stage1 (checksum/method/key port/locals/long-seed 
     'sha1 hash-stage2)
]

I simply don't know how to rewrite in rebol using 'checksum following 
line:

reply=xor(hash_stage1, sha1(public_seed, hash_stage2))

scheme used between client, server:

The new authentication is performed in following manner:

  SERVER:  public_seed=create_random_string()
           send(public_seed)

  CLIENT:  recv(public_seed)
           hash_stage1=sha1("password")
           hash_stage2=sha1(hash_stage1)
           reply=xor(hash_stage1, sha1(public_seed,hash_stage2)

           // this three steps are done in scramble() 

           send(reply)

     
  SERVER:  recv(reply)
           hash_stage1=xor(reply, sha1(public_seed,hash_stage2))
           candidate_hash2=sha1(hash_stage1)
           check(candidate_hash2==hash_stage2)

           // this three steps are done in check_scramble()

scramble-long: func [pass port][
     hash-stage1: checksum/secure pass
     hash-stage2: checksum/secure hash-stage1

     to-string xor hash-stage1 (checksum/secure port/locals/long-seed 
     hash-stage2)  ;.--- what to do here?
]

scramble-long: func [pass port][
     hash-stage1: checksum/secure pass
     hash-stage2: checksum/secure hash-stage1

     to-string xor hash-stage1 (checksum/secure join port/locals/long-seed 
     hash-stage2)
]

rebol [
	date: 24-Jul-2005 
	author: "Anton Rolls"
	comment: {

  Investigating why adding/removing 'merge from effect block seems 
  to change line-width on
		arc, circle etc.:

		ToDo:
		  - try to 

  - It looks like the AGG anti-aliasing is with the default window 
  background color ?

    When MERGE is added, then it's with the actual color that is merged 
    (seems ok and good to me).

    - so try to set b1/color so it's the same as the color anti-aliased 
    against in the merged version

    Perhaps default window background color (200.200.200) is close to 
    the default agg anti-aliasing color ?
		  (do not use custom window color)
		- try a simple LINE
		- report to RAMBO or AGG group
		- submit to RAMBO


  This shows that the addition of 'merge seems to add 0.5... (?) or 
  some scaled factor to the line-width:
	}
]

effect-blk: [
	draw [
		pen black
		line-width 0
		translate 25x25
		scale 1 1 
		circle 0x0 24 ;arc 0x0 24x24 0 270
	]
]
make-2nd-effect: func [/local result][
	result: copy/deep effect-blk
	insert result 'merge

 ;result/draw/line-width: result/draw/line-width - 0.5 ; <- even with 
 this they don't look quite the same

 result/draw/line-width: result/draw/line-width - any [attempt [correction-scr/data 
 * 0.1 + 0.5] 0]
	result
]
refresh: does [
	b2/effect: make-2nd-effect
	show [b1 b2]
	big1/image: to-image b1
	big2/image: to-image b2
	diff/image: xor big1/image big2/image
	same-txt/text: join "same? " big1/image = big2/image
	show [big1 big2 diff same-txt]
]
view/new window: center-face layout compose/only [
	across
	label 80 "scale"
	scroller 200x20 with [data: 1][
		change/dup next find b1/effect/draw 'scale face/data 2
		refresh
	]
	return
	label 80 "line-width"
	scroller 200x20 [
		b1/effect/draw/line-width: face/data * 4
		refresh
	]
	return
	label "line-width correction"
	correction-scr: scroller 200x20 [
		refresh
	]
	return
	b1: box 50x50 [refresh] effect (effect-blk)
	b2: box 50x50 [refresh] effect (make-2nd-effect)
	same-txt: text 200
	return
	big1: image 200x200
	big2: image 200x200
	return
	diff: image 200x200
]
refresh
do-events

Since there is a lot of silence in recent days on this AltME world 
Pekr persaded me to put one announce here:


I'd like to announce important milestone in my personal(occasional 
weekend hobby ;)) JITteR project developement that has just been 
achieved yesterday.


JITteR is lightweight REBOL dialect that enables running JIT compiled 
functions directly from REBOL interpreter.

Such JIT compiled functions can be tens to hundreds times faster 
than REBOL equivalent code.

Usage of JITter is aimed on graphics routines, compressors, codecs, 
generators, number crunching algorithms and various other time-critical 
programming tasks.

The main idea of this project is not to clone all REBOL functionality 
but maintain compatibility in sense of JITteR -> REBOL way so any 
code written in JITteR can be executed(fallback) as plain REBOL function! 
without the need of touching the code.


Currently only REBOL2 version is being tested and x86 CPUs are supported. 
But R3 and other CPUs will be added in later stages of the developement.

Licensing is not yet decided (until the project reach full Alpha 
stage). But the code will be definitely free for non-commercial usage.


Since this release is only 'internal' I hope this announces doesn't 
sound to much 'vaporwarish' :-)


Alpha release is planned to be released to closed group of developers 
in ~2 months.
Feel free to leave any feedback in the Ann-Reply group or PM me.

project features log:


JITteR v0.1.23.3.1 (pre-Alpha version internal release) - 16-May-2010

---------------------------------------------------------------------

- currently only x86 32-bit CPU assembly supported (other CPUs planned 
in Beta stage)

- datatype support: image!, binary!, string!, integer!, decimal!, 
char!, logic! 
- path! lookup support on binary!, image!, string! byte arrays
- math operations: +,-,*,/,<,>,<=,>=,=
- boolean operations: NOT, AND, OR, XOR
- parens support: REBOL-like code evaluation precedence

- supported keywords (REBOL compatible): APPLY(currently on JITTer 
functions only), LOOP, REPEAT, WHILE, UNTIL, BREAK, IF, EITHER, PICK, 
POKE

Tab panels can't be used, because it's XOR. So either show A or B.

Finished support of tuples for all operator actions.

XOR OR and AND have slightly different behavior than REBOL when arguments 
are a tuple and a number. ie:

O> 1.2.1 xor 2015.345 ;== 222.221.222
R> 1.2.1 xor 2015.345 ;== 255.255.255


Which behaviour the community prefers? I believe orca's implementation 
is more correct, but we can change it.

Does anyone use such feature bitwise ops between tuples and numbers?

Jaime thanks for asking...But there's not a simple answer.

The point I am about to make applies to any proposed variant in ORCA 
vs REBOL.


The problem with changing fundamental behaviour is that it makes 
it hard to port applications: think a few years ahead when ORCA is 
a fully operational REBOL clone, and (as an example) (unlike REBOL) 
runs on PDAs. I'd like to use ORCA so I can run an application in 
a PDA; but I want to use REBOL for all my other platforms. And I 
don't want to have to pick through code and/or support two source 
versions because of avoidable differences in behaviour.


On the other hand, an ORCA-only application might benefit from the 
"more correct" implementations of basic operations.


One possible way to square that circle is to have a set compatibility 
flag:
    system/orca/xor: false  ;; gets me REBOL XOR behaviour

I just have to wrap that in an 'attempt and I can keep a common source 
that will run under either.


[I appreciate that there may be performance issues doing it that 
way -- may be better to have compatibly options specified in an orca.r 
file that is only processed at start-up....I'll leave the details 
to the people doing the design]

Priorities would mean more special cases for the evaluation - instead 
of a consistent op! behaviour.

It's not just + * - /, it's for // ** and or xor = > >= <= <> == 
=? too.

The left to right rule is itself quite an improvement in readability 
over the pure form:
>> * + 3 2 5
== 25

i made a script with R3 which vectorizes simple images (initialyy 
to build vectorial fonts usable with the draw dialect) 

I used a lot bitwise operators like OR and XOR on that images as 
a prefiltering process.
I can put in the te trash my work now.

Oldes i used XOR operator on black and white images of letters to 
extract the contours

I don't understand, why XOR and OR should be removed from functioning 
upon image datatype?

I have been playing with converting some R2 scripts to R3.

And I am buiding a perhaps useful list of the things that need to 
change....eg:
      r2  allows: xor 1 2
      r3  either: 1 xor 2
              or: xor~ 1 2
Where would be a good place to start a list like that?

Sunanda: I think, that it is necessary to *discourage* everyone from 
using (xor 1 2) in R2. It is not officially supported anyway.

Some tweaks:
- OR~, not ~OR

- AND~, OR~ and XOR~ work in R2 as well, and should be used instead 
of AND, OR and XOR for prefix use.

Carl has announced the applicability of logical operators to type(set)s 
for a77. At first sight, this duplicates union ( ~ or) intersect 
(~ and) and difference (~ xor). Then again, both sets of operators 
are also defined on bitsets, so there is consistency in this duplication, 
and I suspect that typesets are really bitsets, internally. However, 
there is one extension: and/or/xor may have a single datatype for 
their second operand (also for their first???). This is not the case 
with union etc.

BrianH: 'and, 'or, 'xor are allowed logical operations upon typesets. 
Do you think it would be usefull to allow also 'intersect and 'union, 
to allow creation of combinations?

Argh.... I felt vaguely, that there was an easier way

>> signed16: funco [n][32767 - n xor 32767]
>> signed16 to-integer #{FFFF}
== -1

The other way I used to do it was maintain binary diffs and xor them 
back to update the main binary .. but again that requires the user 
not to run two copies :(

Alternate upgrade method .. download binary patch, read the current 
version, xor it, write it out as the new version .. and then the 
same as in your script above.

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

here is a simple function to swap channels from any image in R2

channel-copy: func [
	raster [image!]
	from [word!]
	to [word!]
	/into d
	/local pixel i b p 
][	
	b: to-binary raster
	
	d: to-binary any [d raster]
	
	from: switch from [
		red r [3]
		green g [2]
		blue b [1]
		alpha a [4]
	]

	to: switch to [
		red r [3]
		green g [2]
		blue b [1]
		alpha a [4]
	]

	either (xor from to) > 4 [

  ; when going to/from alpha we need to switch the value (rebol uses 
  transparency not opacity)
		repeat i to-integer (length? raster)  [
			p: i - 1 * 4
			poke d p + to to-char (255 - pick b p + from)
		]
	][
		repeat i to-integer (length? raster)  [
			p: i - 1 * 4
			poke d p + to to-char pick b p + from
		]
	]
	d: to-image d
	d/size: raster/size
	d
]

>> sext32: func [x] [32768 xor x - 32768]
>> sext32 to-integer #{ffff}
== -1

>> sext16: func [x] [32768 xor x - 32768]
>> sext16 to-integer #{ffff}
== -1

My version seems to be a little bit faster:
>> sext16_v1: func [x] [32768 xor (to integer! x) - 32768]
>> sext16_v2: func [x] [shift shift to integer! x 48 -48]
>> dt [sext16_v1 #{ffff}]
== 0:00:00.00001
>> dt [sext16_v2 #{ffff}]
== 0:00:00.000009

So, for example, if we talk assembler you would of course use an 
XOR instruction to mutate the new-line bit of the value slot.

And I think the point why your definition makes a lot of sense is 
that we can neither observe nor does it matter, if the new-line bit 
is modified directly by XOR or a MOV,XOR,MOV sequence.

To complete the informations, I should probably perform a user poll 
in here. So, here goes:


*For me, one of the main goal of logic operators like NOT, AND, OR, 
XOR is to yield a value, that is used mainly as the CONDITION argument 
of the IF, UNLESS, EITHER, etc. control functions.


*Taking NOT (which is a unary logic operator) as an example, we see, 
that it is compatible with the above mentioned main purpose. The 
goal is achieved by "delegating" other functionalities NOT does not 
perform to COMPLEMENT. It is not possible for NOT to be both compatible 
with IF and perform the operations COMPLEMENT does.


*Taking OR (which is a binary logic operator) as an example, we see, 
that it is incompatible with the above mentioned main purpose, not 
being able to correctly handle some logic combinations, that would 
be compatible with IF. As an example, see the expression
    0 or true

, which cannot be used to yield an argument for IF, although both 
its arguments *are* compatible with IF. Interestingly, there is not 
a shortage of functions that are meant to perform analogical non-logic 
operations. I would like to specifically mention the UNION function, 
which seems to be related to OR similarly as COMPLEMENT is related 
to NOT.

*The question I am asking you is:

- Do you prefer the "logical" solution used in the case of NOT, and 
apply it to other operators like AND and OR as well, or

- Do you prefer the "non-logical" solution used in case of AND and 
OR and apply it to the NOT operator as well, or
- Do you prefer to keep the current state of affairs for R3?

I am for the first alternative, letting AND, OR and XOR work as "logic" 
operators only, "delegating" other (similar) functionalities to functions 
like UNION, INTERSECT, etc.

I misunderstood as well. Thanks for clarifying.

+1 for having AND, OR, and XOR work as logic ops only.

I can see, how it became this way trying to avoid &, | and ^ for 
AND, OR and XOR.

I don't mind AND, OR and XOR being both logical and bitwise ops. 
If there is a problem with the current behavior, I don't remember 
being tripped up by it.

Atm. I prefer the same as you too (the first one), but I would suggest 
some names for the bitwise and, or and xor in the reporting of this.

I feel, the language would benefit from being a bit more strict.

Maybe AND, OR and XOR should only be bitwise, and then introduce 
&& and || (and maybe logical xor ^^, but just maybe).

None is a falsey value (NOT the value returns true), but not a false 
value. If we want to have AND, OR and XOR accept none as a false 
value, this will lead to errors being ignored unintentionally. We 
can do it, but there is a drawback. Still, I prefer that to making 
a separate set of operators for bitwise operations.

I always use AND, OR and XOR in both their logical and bitwise sense. 
There is no confusion because I have to use logic! values for the 
logical behavior. This means that explicit conversions resolve the 
difference visibly.

but brian, the current AND/OR/XOR  *cannot* be used for logical ops. 
 the fact that none isnt' supported is the proof that its not working. 
  bitwise ops already exist in principle with the "set" functions 
 'complement, 'union etc.

There are similar conversions from is-it-zero-or-not to logical, 
from is-it-found-or-not to logical, from is-it-empty-or-not to logical. 
The conditional one isn't different. It is interesting that we don't 
have conditional AND, OR and XOR, but not really bad because of all 
the methods of explicitly converting to logical.

NOT is conditional in REBOL, so it doesn't have the same constraints 
as AND, OR and XOR which are logical or bitwise, depending on the 
types of their arguments.

If you want to make logical versions of AND, OR and XOR separate 
from their bitwise versions, that doesn't make any sense - their 
types already distinguish them. If you want to change AND, OR and 
XOR to be contitional, then the additional ops can behave like the 
current ops behavior: bitwise or logical, depending on argument types.

and in fact XOR is the infamous ALTER.

so I guess we only have to find an new function name for XOR's bitwise 
variant?

>> a: [1 2 3 4] b: [1 2 3 5]
== [1 2 3 5]
>> difference a b
== [4 5]

is exacty what I would expect of XOR on blocks.

I feel a little confused. Are you proposing that DIFFERENCE be used 
for bitwise XOR?

So logically:

>> (#"^(40)" xor #"^(C0)") = (difference #"^(40)" #"^(C0)")

As an example, see the comparison of XOR and DIFFERENCE above.

Actually, I use bitiwse  XOR and OR to perform arithmetic on characters 
in my string encoding utilities script.

It does look a little unusual but probably the equivalents with OR 
and XOR look odd to other people.

It's a long time since I studied set theory but if I remember correctly, 
the union of two sets is not dependant upon the order of the elements 
in a set.


So shouldn't the UNION of two sets of bits really be one of three 
values {0}. {1} or {0,1}.


I know this is knitpicking but I'm very used to XOR being bitwise.

Ladislav, http://issue.cc/r3/1879is a bit complicated when you consider 
that "operator" is used in REBOL jargon only for infix operations.
Your request looks like 3 related tickets:

- Extend the INTERSECT, UNION and DIFFERENCE functions to include 
the current bitwise behavior of AND, OR and XOR, respectively.
- Make operators for those functions (maybe &, | and ^).

- Change AND, OR and XOR operators (and AND~, OR~ and XOR~ functions) 
bitwise behavior to conditional behavior.
Is this a reasonable assessment of your request?

The goal of having less dictionary entries to remember, and having 
the ops be smart, is valid; but in this case I think the meaning 
of the set op funcs (e.g. difference, union, etc.) are *much* clearer. 
Yes, most of us see AND and OR and know what's going on (though it 
sometimes makes my brain stutter a bit when debugging, especially 
XOR :-).

If it's not, then the INTERSECT, UNION and DIFFERENCE proposal could 
be accepted and the BIT-AND, BIT-OR and BIT-XOR proposal (or whatever 
you prefer as an alternate convention) could be rejected. Rejection 
of a proposal is not a problem in this case - rejection of *both* 
proposals is a problem.

I often use the prefix forms of AND, OR and XOR because of the parentheses 
issue. Operations used often, but not always the operators.

the basic problem is that NOT isn't symmetric with AND/OR/XOR .  
  currenty, AND/OR/XOR are bitwise ops.  they are not language control 
flow ops.

Just for starters.....This does it with 12 XORs (three per swap).

But the tricky bit may be pre-computing the from-list and to-list 
mapping

;; function to do the swap

swap-items: func [
   data [block!]
   from-list [block!]
   to-list [block!]
   /local
    ind1
    ind2
 ][
 for n 1 length? from-list 1 [
     ind1: from-list/:n
     ind2: to-list/:n
 
     data/:ind1: xor data/:ind1 data/:ind2
     data/:ind2: xor data/:ind1 data/:ind2
     data/:ind1: xor data/:ind1 data/:ind2
     ]
     return data
    ]

;; Sample run    
     block: [4 5 6 1 2]
     probe swap-items block [1 2  1 1] [3 4 5 2]
    [1 2 4 5 6]

Normally all op!s are somehow related with math, as we can consider 
equality tests (=, !=, > etc) and logical operations (xor, and etc.) 
as math operations.

TO and IN are different by this way, they are not related any math 
operation, they don't test, they don't calculate anything.

And one of them should have a precedence the other, or we should 
use parens, or can we say always left-to-right:

>> o: context [a: "3"]
>> 'a in o to integer!

Can you comment on what World is doing when fed incorrect arguments? 
In these two cases below, both R2 and R3 throw an error....
       w> 1-jan-2011 xor 1-jan-2012
       == false
       w> 1-jan-2011 and 1-jan-2012
       == true

It relates to the true/false value of different values. Using IF, 
only logic false and none will fail the IF. All other values will 
fulfill the IF. I have brought this idea to AND, OR, XOR etc. So 
because you can write:

w> if 1-jan-2011 [true]
== true

you can also write

w> 1-jan-2011 and 1-jan-2012
== true

Okay.....Yet is is confusing that bad args are caught in some cases 
but not in others:
       w> 1-jan-2012 xor 555
       == false
       w> 1-jan-2012 xor 5x5
       Valid pair: 5x5
       ** Error: xor is missing one or more arguments
       ** Near: 1-jan-2012 xor 5x5