World: r3wp

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

no, it creates a  binary :-)

pekr you seem to miss that a value and a litteral are two different 
things.

I meant a value stored in ram.

OK, so in my above case, I am supposed to pad #{8000} to #{00008000} 
... what the hell do I do, if I am on 32 bit R3 version, not having 
64 bit integer? How do I know?

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

Maxim, you're wrong on this one. 0x8000 is always an integer. It 
has nothing to do with #{8000}.

10 represents the number, but it can be stored in a variety of ways.


0x800 represents the number, just in another notation.  like 10  
is written   110   in binary  or   A   in hex

that will depend on the compiler.

Brian: Max meant the binary #{8000} is a different value ....

Right. A notation that REBOL doesn't support. So Pekr was trying 
to use #{8000} instead, not realizing that it referred to a different 
concept altogether (one which Python has no support for, ironically).

>> append #{0000}  #{8000}
== #{00008000}

;-)

Max - append and join are broken - it is CCed ...

well the above worked in my R3... its copy/pasted from R3 console

APPEND works with appending binaries, just not blocks of binaries. 
The ticket is specific.

At least Python has no syntax support for the concept that #{8000} 
represents in REBOL.

ironically -> cooincidentally :)

BrianH: now I will get you ... what value should to-integer #{8000} 
return? It now returns 32768!!! And according to your theory, it 
should be equal to padded value, hence to-integer #{8000000000000000}, 
because you just said, that I can't expect #{8000} to be the lowest 
bytes ...

should I put into CC, that to-integer #{8000} is wrong then? :-)

OK, going to sleep. Will wait for eventaully others to express their 
opinion. I understand your points, and will adjust accordingly, it 
is just that it imo sucks for the usage case I needed. For me integer 
to-binary and reverse operations are not safe to combine. That might 
confuse some ppl, and will need good Docing ....

Hmm, actually I still think that not considering #{8000} a concrete 
(32768) value is a bug and totally wrong assumption. It IS a concrete 
value, period. It is just that R3 allows me to enter it without the 
padded higher bytes. And hence - the concrete value should be computed 
internally accordingly. Easy as that ....