World: r3wp

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)

16bit

We still use 8-bit CPUs, it is just I don't expect REBOL to run on 
them :-)

They were called 8-bit, AFAIK, but worked with 16-bit integers

That's the 8088 and its like. Real 8bit CPUs worked in bytes.

I worked on CPM and DOS 1, so I know the difference :)

I meant e.g. http://en.wikipedia.org/wiki/Intel_8080

(worked on in this case not meaning developing the OSes, but developing 
*on* the OSes)

The 8bit vs. 16bit thing as most understand it referred to address 
space, not integer size :)

The same was with Amiga and Motorola, just reverse, no? MC68000 was 
32bit CPU with 16bit bus, whereas adress space and registers were 
32bit?

Actually, I remember MC68000 being called 16-bit processor (which 
is analogical as for I8080, mentioning the bus size, not the address 
space, or the integer size)

Ah, the good old days :)

:-D

Anton, that might be a good syntax. A "shame" that x is already taken 
for pairs.

Henrik - I just wanted to say the same (re "x") ... I thought about 
"*", but not sure ...

I prefer to think that "shame" was put in quotes sarcastically :)

From R3 twitter:

The first R3 embedded extension function evaluated! I think many 
of you are going to like this capability.