r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Pekr
21-Apr-2010
[2248x3]
... 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?
Ladislav
21-Apr-2010
[2251]
>> ; 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
Pekr
21-Apr-2010
[2252]
R3:

>> to-hex -1
== #FFFFFFFFFFFFFFFF

>> to-integer #{FFFFFFFFFFFFFFFF}
== -1
Ladislav
21-Apr-2010
[2253]
how is that related?
Pekr
21-Apr-2010
[2254x3]
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?
Ladislav
21-Apr-2010
[2257]
I suppose, that I already wrote it abov e
Pekr
21-Apr-2010
[2258]
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 :-)
Ladislav
21-Apr-2010
[2259]
Right, it is a 32-bit binary value being converted to a signed integer.
Cyphre
21-Apr-2010
[2260]
Ladislav, so you think it should work this way in R3?

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

>> to-integer #{FFFFFFFF}
== -1
Ladislav
21-Apr-2010
[2261x4]
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.
Pekr
21-Apr-2010
[2265]
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 :-)
Cyphre
21-Apr-2010
[2266]
ok, but then we would need a way you convert -1 to 8/16/32/64 binary 
too right?
Pekr
21-Apr-2010
[2267]
I mean - left padded ...
Ladislav
21-Apr-2010
[2268x2]
Cyphre: Not necessarily.
(the 64-bit result is OK)
Pekr
21-Apr-2010
[2270]
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)
Ladislav
21-Apr-2010
[2271]
but, if the TO-INTEGER function obtains a 32-bit binary, it is not 
reasonable to expect it is not 32-bit
Pekr
21-Apr-2010
[2272]
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 :-)
Cyphre
21-Apr-2010
[2273]
Ladislav, ah, yes, you are right..then I think that your propsal 
is reasonable.
Pekr
21-Apr-2010
[2274x3]
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 :-)
Ladislav
21-Apr-2010
[2277]
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)
Pekr
21-Apr-2010
[2278]
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 :-)
Ladislav
21-Apr-2010
[2279x2]
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)
Pekr
21-Apr-2010
[2281]
... and according to that description, current result is OK ... no?
Ladislav
21-Apr-2010
[2282]
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.
Pekr
21-Apr-2010
[2283x3]
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 ...
Steeve
21-Apr-2010
[2286]
what do you mean by no fast way to pad binaries ?
Pekr
21-Apr-2010
[2287]
I mean - #{FFFFFFFF} being treated as #{00000000FFFFFFFF} for OR 
and AND operations ....
Steeve
21-Apr-2010
[2288]
i don't understand why you don't chose the opposite way (dealing 
with integers) it's simpler and faster
Pekr
21-Apr-2010
[2289x2]
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.
Steeve
21-Apr-2010
[2291x2]
hum ok, you want pad-bin as fast as possible...
R3 ?
Pekr
21-Apr-2010
[2293]
yes, R3 .... I posted one func, did you see it?
Steeve
21-Apr-2010
[2294]
yup
Pekr
21-Apr-2010
[2295]
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 ...
Maxim
21-Apr-2010
[2296]
pekr, you can easily build an extension which handles your specific 
binarie wishes and it will be VERY fast.
Pekr
21-Apr-2010
[2297]
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 :-)