World: r3wp

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.

Using language like "insane" to describe the above is hyperbole. 
I don't respect that; it's an overreaction. Why not say instead, 
"the following result is still confusing to me". (I'm having the 
same problem with my parents and with myself, we are using too much 
extreme inaccurate language, and it's causing emotional stress between 
us.)

Wow, what a fuss :)

What prevents you to adjust the size of the binary to fit the chosen 
size ?

>>(skip to-binary 1022 6) or #{8000}
==#{8324}

Pekr, you are right when saying, that binary OR uses different padding 
(right) than conversion to integer (left).

As far as I am concerned, the left padding for conversion to integer 
looks more convenient than right padding, "producing" a useful result 
more often.

Regarding the OR operation: I guess, that it *could* use left padding 
too, but, in that case, I am not sure, whether left padding would 
produce a more useful result more often, than right padding. (although 
you provided one case, where left-padding *would* be more useful) 
Nevertheless, I do not think, that padding of these two operations 
has to be the same

#{83FE}, I meant

From what I can tell above, we just need a way to represent numbers 
properly in any base.

And Pekr is using binaries, because they happen to sort of fit into 
binary operations in some cases, which makes them look incomplete.

How about a base! datatype, which would be a number! ?

#(10000000)2 == 127


Quick and probably bad example. An issue would be how to convert 
between different bases.

whoops, 128, it should read.

pardon my basic binary skills. :-)

I would prefer less syntax, if possible, maybe something like 2_10000000
(Remember we have 2#{10000000}, but it's a binary! of course.)

Anton - insane is just that ... insane :-) It is just word. I did 
not say Carl, BrianH or anyone else is insane, having some arguments. 
REBOL is not religion, as Brian says ... it is a tool. And I want 
the tool to work correct way, if possible. So - stop being stressed 
about someone claiming something is insane :-) 


The question to all above is - what is the correct behaviour. The 
qeustion even is - what is correct about correctness? I know from 
the past, that Carl really cares about simple things being simple. 
I can't remember the case, but I do remember I pointed out something 
will confuse ppl, and I was right - we could see the same kind of 
questions by novice again, and again, and again.


I think that if you claim, that to-integer #{8000} allow many interpretations, 
how is that we have choosen the concrete one? (32768) Because it 
is what we would expect. You might think that I don't understand 
what BrianH or Max or You talk about. Whereas only Ladislav got the 
correct answer for me - if it would hurt to have reverse padded OR 
operation.

The behavior was what I expected, so clearly expectations vary :)

Steeve: I understand your example, no problem about it, but try to 
adapt it to my  (non-existant yet :-) possible R3 cell phone implementation, 
which will use 32 bit integers (not sure if it would ever happen). 
Then, if you want your code being cross platform, your code complicates, 
no?

>>(skip to-binary 1022 6) or #{8000}
==#{8324}

Andreas - thanks for reminding me we have following form: 
>> l: 2#{11111110}
== #{FE}

>> print l
#{FE}


I just wanted to ask, if it would be possible for interpreter to 
"preserve" original written format for the output purposes?

It might help to have an entry in system/catalog or something that 
says the length of integers in bytes. Or you could just make your 
own local constant using like this:
>> int-size: length? to-binary 1
== 8

Then you can use the constant to make your code portable.

BrianH: I know :-) It is just that for the simple purpose of OR, 
you have to do all those conversions and tests for the integer size. 
Then original "shortcut" format of #{8000} be better avoided in the 
code.

is there possibility we would have 'pad function in REBOL, native, 
which in the case of binary would auto-padd it to the "full format"? 
:-)

When I am adapring code from languages with C-like integer syntax 
I resolve the constants to regular integers ahead of time and then 
put the original syntax in comments. Works great, no conversion overhead 
at runtime. You should try it.

A PAD function would be useful.

I think we tried some 'pad efforts in the past, but that function 
gets easily complicated, as far as our expectations might go ...

But PAD would obviously not be for autopadding, it would be for explicit 
padding. Don't make the interpreter attempt to read your mind :)

We made a MOVE function to resolve such discussions, we can do the 
same with PAD.

Is there a reason, why 'shift (as opposed to R2), does not allow 
binary as an argument?

SHIFT in R3 is a lower-level, much faster function. No other particlar 
reason though.

My question basicall was, if it would work with new binary represenation 
in R3. I think that there should be no reason to not to. We could 
add CC ticket for it, if not already there ...

Go ahead. It's not already there, afaik.

SHIFT in R3 is a pure function though, non-modifying. You might be 
better off with a different function for binaries.

The changes to SHIFT are a good model for how to make PAD simple: 
Builder function, positive to pad left, negative to pad right, padding 
value required,  maybe an /into option. Make it simple enough and 
it could be fast even as a mezzanine.

We might want to reverse that positive/negative thing though since 
SHIFTing left is really padding right with bits though.

Pekr: "if you want your code being cross platform, your code complicates" 
- certainly! In such cases, left-padding does not work reliably, 
in fact!

Hmm, because I can't do shift on binary, enbase/base is giving me 
following result (understandable, as to-binary creates 64 bit binary)

>> enbase/base to-binary shift to-integer (copy l) -8 2

== {0000000000000000000000000000000000000000000000000000000010000011}

whereas:
>> enbase/base 2#{11110000} and 2#{10110000} 2
== "10110000"


Correct too? So when using shift, I need to use different scenarios, 
if I want bits represenation (copy/part)?

Example:
>> to integer! #{FFFFFFFF}
== 4294967295

(while you migth want to obtain -1)

Preconversion is usually the best bet for this kind of thing.

Ladislav - interesting. So I better first check, what platform (integer-side 
wise) I am running on, and adjust accordingly? E.g.

>> 8 * length? to-binary -1
== 64

Yes, e.g. your #{8000} may in fact be interpreted as -32768

Yup. And remember that all of those TO-BINARY calls and binary constants 
have overhead, so you should precompute constants whenever you can. 
This makes yor code *much* faster.

(as it was in 8-bit CPUs)