World: r3wp

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

Pekr, you do realize that TO-INTEGER #{8000} is a conversion of an 
incomplete binary, an operation, right? And that 0x8000 is syntax 
for an integer value? REBOL doesn't have hex syntax for integers, 
or any default interpretation of binary values as being of a different 
datatype. Just like Python doesn't have syntax for binary values 
(unless I'm mistaken about that last bit).

#{8000} could just as easily be an incomplete decimal or money, or 
a malformed character, as it could an incomplete integer.

#{8000} is a concrete value. It just isn't an integer.

#{8000000000000000} is the binary equivalent to an integer, though 
not without explicit conversion.

Any padding is done during the conversion, but that is only for your 
convenience. It is not an inherent quality of the source value.

All of the TO whatever binary! conversions also allow the binary 
to be longer than the target value, ignoring the rest of the data. 
This comes from the assumption that the binary is a stream that you 
are converting and the rest of the stream is other values that you 
will be converting later. If the value is too short then it is assumed 
that you did a COPY/part on the stream for alignment and padding 
purposes, so it will be nice to you, but direct operations on binaries 
are assumed to have comparable lengths. And there are no implicit 
conversions to or from binaries, as a rule. The behavior is very 
consistent.

>> to-binary -0.0
== #{8000000000000000}
>> to-binary -9223372036854775808
== #{8000000000000000}


So, what does #{8000000000000000} mean? It means #{8000000000000000}, 
nothing more without explicit conversion.

Out of curiosity, does Python have a literal syntax for an array 
of bytes? That would be the equivalent of binary!.

Yes, it has.

Python3, that is: b'....'.

Thanks, now at least we have something to compare :)