World: r3wp

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

And in Python 2, a (non-unicode-) string is nothing but an array 
of bytes.

Not that dissimilar to R2, that.

Quite similar in fact, except for the default encoding.

Pekr, I agree with BrianH (as I almost always do).

It seems the confusion is that C or Python's integer representation 
syntax and Rebol's binary datatype look similar, because they both 
use hexadecimal. But 0x8000 in C or Python is really an integer and 
has to fit inside an integer type with some specific size. Rebol's 
binary type is a series type and can be as long or short as you want 
(well, measured in 8-bit chunks, octets), and it doesn't make any 
assumptions as to what the meaning of those octets is.

In Rebol I miss being able to represent integers the way C does, 
it makes translation a bit more difficult.

And just to add my two cents: I find the current R3 behavior to be 
easily understandable and totally sane.

I haven't really gotten into R3 yet. I only played with binary/integer 
conversions in R2.

Things are much better in R3 :)

Imagine TO-BINARY integer! just working like it's supposed to :) 
Heaven!

Yes, that does look better :)

So just to add what Brian already explained nicely above: #{8000} 
is syntax for a sequence of bytes. The equivalent in Python would 
be b'\x80\x00'. 32768 is syntax for an integer, same in Python. Additionally, 
Python has alternative syntax for the same integer: 0x8000, 0o10000, 
0b1000000000000000; for those literals, REBOL has no corresponding 
syntax.

And I don't think those literals are missed, in REBOL.

As you can already glance from the above, we have a nicer literal 
way to specify sequences of bytes. This goes even further: we can 
write #{F0} as 2#{11110000}, for example.

And the only important thing for correctly using binaries, is not 
to mistake a binary for some other type just because it could validly 
represent this other type. #{0001} is neither 1, nor true, nor $1, 
nor #1, nor ...

You still talk about the syntactic sugar, but that is imo irrelevant. 
If we have so cool and open dtype, which can represent "anything", 
then allowing integer to binary and vice-versa conversion, should 
be prohibited! How is that we decided, that to-integer #{8000} is 
actually 32768? That is absolutly concrete value, it does not allow 
any other interpretation, no? So how is that, when ORring with such 
a value, such expectation does not stand anymore?

I still think, that OR/AND applied from the right side would not 
hurt anyone. It would just work correctly imo. Max's explanation, 
that binary is just a stream does not imo stand any valid argument 
here, because - when you already decide to apply AND/OR, you decide 
at certain time, with certain known binary value,no matter wher in 
the stream you are ...

So once again ... the following result is imo insane, and I wish 
a luck anyone trying to explain it in the docs :-)

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

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

You just ORed together two binaries. How the hell is rebol supposed 
to know that you consider them to represent 64-bit integers? The 
above expression does not specify anywhere that these are to be treated 
as 64-bit integers.

to-integer #{8000} -> 32768  "... it does not allow any other interpretation, 
no?"   --- Yes, it could easily allow many other interpretations, 
for example, the first byte of the binary could become the least 
significant 8 bits of the integer, instead of the most significant 
8 bits as it is now.