World: r3wp

... and then - instead of Python equivalent code with 3 lines of 
shifting, I can just perform:

append result to-char my-binary/7
append result to-char my-binary/8

... or so I think ...

... the REBOL way, not just translated Python code ...

Is there any resolution to this topic? (Console) ... when playing 
with R3, I can't stand that ugly Windows "console" more and more 
:-) We can't even have multiline cut & paste :-(

http://www.rebol.net/r3blogs/0282.html


I don't remember the outcome - will we put R2 console back to Windows 
distro? Or wait for our own GUI based one?

>> ; R2 code converting integer -1 to 32-bit binary
>> debase/base to-hex -1 16
== #{FFFFFFFF}
; R3 code converting the said binary to integer
>> to integer! #{FFFFFFFF}
== 4294967295


As far as I am concerned, it looks incompatible to me, and I would 
prefer -1 to be the result of the conversion in R3

R3:

>> to-hex -1
== #FFFFFFFFFFFFFFFF

>> to-integer #{FFFFFFFFFFFFFFFF}
== -1

how is that related?

btw - issue! is no more convertible to binary in R3. Is it because 
issue! is a string type, whereas binary! kind of divorces with string 
type? :-)

How is that related? I don't know. Most probably I don't understand 
the problem you are trying to describe. Why should to-integer! #{FFFFFFFF} 
of said value be wrong?

you would expect it to be -1 probably, right?

I suppose, that I already wrote it abov e

hmm, but it is 4 byte value in 8 byte (64bit) environment, no? Why 
should it roll to -1? Well, I think it will be better for me to let 
the topic to those who understand it, and watch the outcome :-)

Right, it is a 32-bit binary value being converted to a signed integer.

Ladislav, so you think it should work this way in R3?

>> to-integer #{00000000FFFFFFFF}
== 4294967295

>> to-integer #{FFFFFFFF}
== -1

yes

(at least to me it makes sense)

But, surely, it would mean, that e.g. to-integer #{FF} should yield 
-1 too

As well as to-integer #{FFFF}, etc.

And I am standing on the other side of the barricade ... preferring 
to regard this thing being always right padded, in regards to full 
64bit slot :-)

ok, but then we would need a way you convert -1 to 8/16/32/64 binary 
too right?

I mean - left padded ...

Cyphre: Not necessarily.

(the 64-bit result is OK)

This is why I originally objected, and started all this discussion 
... conversion is left padded (your binary value to the right), whereas 
OR/AND are right padded (value applied from the left)

but, if the TO-INTEGER function obtains a 32-bit binary, it is not 
reasonable to expect it is not 32-bit

This is what guys tried to tell me - it is not probably being a 32 
bit binary ... it is just 32 bits, placed somewhere along the way 
in 64 bit slot, or in the binary stream :-)

Ladislav, ah, yes, you are right..then I think that your propsal 
is reasonable.

with such explanation, your 32 bit binary is just first 32 bits of 
64 binary, and then the result might be regarded being OK,no? :-)

but - the way Cyphre wrote his example above, it might be understandable 
... simply put, if you want full slot, you have to padd it from the 
left ... or it is just 32 bit value, and hence should yield -1

I think now I finally understand, what you mean :-)

first 32 bits of 64-bit binary

 is nonsense (you cannot convert "first 32 bits of 64-bit binary" 
 to integer in any reasonable way)

you can - you just take first 32 bits, regard it being a 32bit binary, 
but you still pretend it comes from 64 bit slot ... and convert it 
:-) (just a joke :-)

the only thing you can do is to convert "last 32 bits of 64-bit binary"

(that is actually the description of what is going on currently in 
the TO-INTEGER function)

... and according to that description, current result is OK ... no?

Yes, the current result is OK, if you pretend, that you did not obtain 
a 32-bit binary. But, I am not schizophrenic enough to be able to 
pretend I did not obtain 32-bit binary, when I did.

I think I will be OK with either solution .... (as I can fully see 
the consequences), I just need it being documented on some examples 
.....

I can = I can't

if OR and AND work "from left" ... then your proposal of #{FFFFFFFF} 
being -1 is logical too .... but guys might not like it, because 
in such a case, you can't easily convert to integer, unless you pad 
... and  we have no fast way to pad binaries currently ...

what do you mean by no fast way to pad binaries ?

I mean - #{FFFFFFFF} being treated as #{00000000FFFFFFFF} for OR 
and AND operations ....

i don't understand why you don't chose the opposite way (dealing 
with integers) it's simpler and faster

well, why not scrap binary altogether, no? What is binary for, if 
I should use integers? All docs describing some interface, mostly 
talk hexa. I know that hexa is not binary, but I want to see, what 
is happening with my bytes. Something like  4294967295 is telling 
me nothing. And putting binary/hexa helpers in comments is strange 
way of doing things. I want to see bytes, and bits ....

I can understand, that if you are really experienced, you might prefer 
integers, and shifting, etc.

hum ok, you want pad-bin as fast as possible...

R3 ?

yes, R3 .... I posted one func, did you see it?

yup

well, it's crap :-) The computation of existing int-size each time 
is not probably necessary. Maybe if we have it as a constant somewhere 
in system structure, it might be faster ... it is just for my testing 
purposes, not really a show stopper. I might in the end use integers 
as well, it is just that I was never good in binary handling, and 
it helps me to see, what is happening with bytes and bits ...

pekr, you can easily build an extension which handles your specific 
binarie wishes and it will be VERY fast.

I am not saying I can't .... I can as well start with mezzanines 
... good enough for my testing purposes, or even for target purpose 
= send few bytes of control commands to router :-)