World: r3wp

also - is following operation what is expected?

>> lx: lx or #{8000}
== #{80000000000003FE}

>> to-integer lx
== -9223372036854774786

Whereas I would expect OR being performed on the lowest bytes!

>> #{8000} or #{03FE}
== #{83FE}

>> #{8000} or #{03FE}
== #{83FE}

just like strings return chars.

I find binary handling, along with inability to join binary resuls 
severyl broken

Max - this is imo wrong ... how is that usefull? I did not ask it 
return integer ... imo /index should still return original type

binary is a string of  bytes, so that it returns 8 bit integers to 
me is VERY usefull.

what you say is equal to:

a: [1 2 3 4 5 6]
a/3
== [3]

binary is a series, and indexes return, like all other series, the 
element which constitutes it at the index you give it.

OK, I can accept that ... but is R3 OR operation, performing OR on 
the higher bytes correct?

If you are concerned about alignment, manage it yourself. The behavior 
is extremely consistent, so that such management is easy.

Brian:  how is that supposed to be easy? The way it is, I have to 
count on the internal representation binary size - here 64 bits ...

I am asking binary 1024 to be ORred with binary #{8000}, the result 
is imo crap :-)

Yes, but that 64 bits is a known, consistent quantity. Very predicatble.

but the result is imo wrong anyway, no?

This is correct:

>> (to-binary 1022) or (to-binary 32768)
== #{00000000000083FE}

No, binaries are right-padded. You should have been ORing with a 
binary of the proper sixe. R3 was nice enough to add the 0s that 
you didn't provide. It's just your assmption that was off :(

sixe -> size

no, it is not ...

>> to-integer #{8000}
== 32768

What assumption are you talking about? If you were right, then above 
binary should be paddedd too ...

I was orring original converted 1022 with 32768 and got a crap ...

If I should care about internal representation of binary, then it 
is not usable datatype for me. How are my operations supposed to 
be fast?

TO-INTEGER and TO-BINARY integer left-pad. OR and AND don't pad at 
all (in theory), they just make up for your error in not providing 
the whole binary. It is like blocks and none.

can't you see that? Following iperations are imo compatible, and 
should provide me with identical results ...

>> (to-binary 1022) or (to-binary 3278)
== #{0000000000000FFE}

>> (to-binary 1022) or #{8000}
== #{80000000000003FE}

>> to-integer #{8000}
== 32768

You were assuming padding, when there is no way to pad those operations 
without breaking someone's assumptions. If you are doing binary conversions 
and working with binary values you are assumed to know what you're 
doing.

simply put, in second case, 1022 is not orred with 32768

No, OR/AND should be applied from the right side, not from the left 
side ....

pekr,  there are things in Computer science which just are.   Just 
like there are things in maths, which just have to be accepted. 


R3 isn't inventing much of anything here, its actually much closer 
to normal boolean algebra than R2 ever was... FINALLY.   


in binary algebra, normally, things are right padded when sizes don't 
match... that's just how the maths behind it where defined long ago.


binary manipulation is an advanced topic, and you can't assume anything.

Simply put, you are assuming that TO-BINARY and TO-INTEGER are reversable 
when you don't provide the whole binary equivalent of the integer. 
There is no reason that this would be true.

non reversable operations are evil ... can't remember the case, but 
we already had such discussion in regards to some R2 area ....

Once again - you are imo wrong. R3 should not allow to enter any 
other than full binary padded format then!

There's no reason that the operation *would* be reversible. The TO-INTEGER 
was correcting for an incomplete binary in a DWIM way. If you had 
provided the whole binary it wouldn't have had to do that. And the 
TO-BINARY had a whole integer, so it didn't have to correct.

How is that in Python, they can safely do it?

 elif l < 0x4000:
            l |= 0x8000
            self.writeStr(chr((l >> 8) & 0xFF))
            self.writeStr(chr(l & 0xFF))

The second line is - l: l or #{8000}

What if I will have 32 or 128 variant of REBOL? Will I have to adjust 
my expressions, hence change my code? There is no reason to not perform 
OR/AND on the lowest byte, not the highest byte imo ...

pekr,  to-integer is a helper func.  its like form, not mold.

you shouldn't be using to-integer.. for binary arithmetic.

rebol is reversible:
>> b: to integer! a
== 32000

>> b: to binary! a
== #{0000000000007D00}

>> a: to integer! b
== 32000

I mean 32bit or 128bit

It is not that Python was doing it "safely", it was that Python was 
doing it differently when there is no standard for what to do here.

OK, one other areas, where R3 makes things difficult ...

Pekr, binary operations are assuming that the binary is part of a 
stream. The "lowest" byte could be megabytes away.

And I was wrong, the Python in your example was not operating on 
binaries at all, it was operating on integers that were specified 
in hex syntax, which is a completely different thing that REBOL has 
no support for at all. Not the same thing.

binary streams and binary arithmetics are different issue to me ...

0x8000 and #{8000} are completely different concepts.

pekr... here I must say, you really do not know what you are talking 
about.


all the binary changes brought to R3 are due to user responses about 
how fucked up it really was to use binary stuff in R2.   really. 
 I had to build binary data-driven TCP servers in R2, for example, 
and I had to use so many shitty work-arounds and fix up numbers .. 
it was an ordeal.


R3 makes binaries, clean, no hassle and simple.  they are a simple 
series of bytes, nothing more.


they are manipulated from the start to the end in that order.  that's 
all there is to it.

0x8000 is an integer specified in a different syntax, one which REBOL 
has no equivalent to but C does.

and 0x8000 will be a different value based on what variable type 
it is assigned to.

0x8000 can be:

 #{8000}, #{00008000}, or  #{0000000000008000}

you can't tell .

So once again - I can work with two binaries being converted at the 
SAME time:

>> (to-binary 1022) or (to-binary 3278)
== #{0000000000000FFE}

But I can't work on two binaries stored at different time:

>> l: to-binary 1022
== #{00000000000003FE}

>> l or #{8000}
== #{80000000000003FE}

Max - please stop this fanboyism. I know why R3 was brought to us, 
and I know how fucked up R2 binary was. I am glad we are converting 
to binary as one value, not as separate values, like in R2, that 
was not usefull. But my above case will make headache to many ppl, 
I can bet ...

pekr... have you been reading... #{8000} is NOT A NUMBER its a SERIES 
OF BYTES.


you keep refereing to binaries as if they where numbers.  THEY ARE 
NOT

and 0x8000 will be a different value based on what variable type 
it is assigned to.
 ... do you REALLY mean it? 0x8000 is just one value, period ...

... and you are talking about CERTAIN binary value as of stream of 
unknown position, hence not having value at all :-)

to-binary 1022  creates a string  16 bytes (64 bits).