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

World: r3wp

[!REBOL3]

Henrik
20-Apr-2010
[2167x3]
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. :-)
Anton
20-Apr-2010
[2170]
I would prefer less syntax, if possible, maybe something like 2_10000000
(Remember we have 2#{10000000}, but it's a binary! of course.)
Pekr
20-Apr-2010
[2171]
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.
BrianH
20-Apr-2010
[2172]
The behavior was what I expected, so clearly expectations vary :)
Pekr
20-Apr-2010
[2173x2]
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?
BrianH
20-Apr-2010
[2175x2]
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.
Pekr
20-Apr-2010
[2177x2]
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"? 
:-)
BrianH
20-Apr-2010
[2179x2]
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.
Pekr
20-Apr-2010
[2181]
I think we tried some 'pad efforts in the past, but that function 
gets easily complicated, as far as our expectations might go ...
BrianH
20-Apr-2010
[2182x2]
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.
Pekr
20-Apr-2010
[2184]
Is there a reason, why 'shift (as opposed to R2), does not allow 
binary as an argument?
BrianH
20-Apr-2010
[2185]
SHIFT in R3 is a lower-level, much faster function. No other particlar 
reason though.
Pekr
20-Apr-2010
[2186]
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 ...
BrianH
20-Apr-2010
[2187x4]
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.
Ladislav
20-Apr-2010
[2191]
Pekr: "if you want your code being cross platform, your code complicates" 
- certainly! In such cases, left-padding does not work reliably, 
in fact!
Pekr
20-Apr-2010
[2192]
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)?
Ladislav
20-Apr-2010
[2193x2]
Example:
>> to integer! #{FFFFFFFF}
== 4294967295
(while you migth want to obtain -1)
BrianH
20-Apr-2010
[2195]
Preconversion is usually the best bet for this kind of thing.
Pekr
20-Apr-2010
[2196]
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
Ladislav
20-Apr-2010
[2197]
Yes, e.g. your #{8000} may in fact be interpreted as -32768
BrianH
20-Apr-2010
[2198]
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.
Ladislav
20-Apr-2010
[2199]
(as it was in 8-bit CPUs)
BrianH
20-Apr-2010
[2200]
16bit
Pekr
20-Apr-2010
[2201]
We still use 8-bit CPUs, it is just I don't expect REBOL to run on 
them :-)
Ladislav
20-Apr-2010
[2202]
They were called 8-bit, AFAIK, but worked with 16-bit integers
BrianH
20-Apr-2010
[2203x2]
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 :)
Ladislav
20-Apr-2010
[2205]
I meant e.g. http://en.wikipedia.org/wiki/Intel_8080
BrianH
20-Apr-2010
[2206x2]
(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 :)
Pekr
20-Apr-2010
[2208]
The same was with Amiga and Motorola, just reverse, no? MC68000 was 
32bit CPU with 16bit bus, whereas adress space and registers were 
32bit?
Ladislav
20-Apr-2010
[2209]
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)
BrianH
20-Apr-2010
[2210]
Ah, the good old days :)
Ladislav
20-Apr-2010
[2211]
:-D
Henrik
20-Apr-2010
[2212]
Anton, that might be a good syntax. A "shame" that x is already taken 
for pairs.
Pekr
20-Apr-2010
[2213]
Henrik - I just wanted to say the same (re "x") ... I thought about 
"*", but not sure ...
BrianH
20-Apr-2010
[2214]
I prefer to think that "shame" was put in quotes sarcastically :)
amacleod
20-Apr-2010
[2215x2]
From R3 twitter:

The first R3 embedded extension function evaluated! I think many 
of you are going to like this capability.
A few days old but I did not see mention of it here.