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

World: r3wp

[Core] Discuss core issues

Pekr
19-Apr-2010
[16385x2]
would it be possible to have more operators? In !Mikrotik group, 
I am trying do some stuff for MT routerOS API. Thanks to Anton, I 
can now proceed. When "studying" Python code, I found segment like:

elif l < 0x4000:
     l |= 0x8000


1) they can directly compare 'l of integer type to binary value. 
But I might make wrong conclusion here. But 'l is really result of 
len('string here') operation. But - even if so, I don't miss such 
an automation, as I can always write if l = to-integer #{8000}


2) Second line is more interesting - I did not find precisely |=, 
but found e.g. /= ... and it translates like do some operation, and 
assign. In this regard, the only comparable operator of REBOL is 
++ or --, but in R2 this is just mezzanine, in R3 native. But if 
I am right, their code:

l |=0x8000

R3:
l: (to-binary l) or #{8000}


So, if I would assume 'l being of correct type already (binary here), 
would it be possible to have?:

l |= #{8000}


Hmm, that is not probably compatible with REBOL parser and REBOL's 
assigment operator, which is :
If I am completly wrong, then please ignore me, I am not that much 
into the language design stuff :-) But why don't we at least have 
& for 'and, and | for 'or shortcuts?
Steeve
19-Apr-2010
[16387x2]
What's the gain ?
Anyway, you can create your own alias.
In R3 >
|: :or
&: :and

In R2 >
alias 'and "&"
alias 'or "|"
Pekr
19-Apr-2010
[16389x2]
you could use the same (R3 way) aliasing aproach in R2 too, no?
& and | are easy to add. The gain is to have apply & modify operation. 
Maybe there is no gain ... Simply instead of a = a + 10, you can 
write in python a += 10 in Python.
BrianH
19-Apr-2010
[16391x2]
User-defined operators are planned for R3, but for now you have to 
use one of the existing operators, possibly renamed. If you can switch 
to prefix ordering you are less limited.
If R2 the built-in operators are special-cased in the DO function, 
so you can't do the renaming trick.
Pekr
19-Apr-2010
[16393]
Is there any bits converter in REBOL? Or not even in rebol? I mean 
- how do I get from 255 or FF to "11111111"? :-)
BrianH
19-Apr-2010
[16394]
In R3:
>> to-binary 255
== #{00000000000000FF}
>> enbase/base to-binary 255 2

== {0000000000000000000000000000000000000000000000000000000011111111}
>> enbase/base take/part/last to-binary 255 1 2
== "11111111"


The to-binary part gets more difficult in R2 because of the aforementioned 
bugs in the semantic model.
Steeve
19-Apr-2010
[16395]
R2:
>> enbase/base #{FF} 2
== "11111111"
BrianH
19-Apr-2010
[16396]
Steeve, the enbase isn't the problem in R2, it's the to-binary.
Steeve
19-Apr-2010
[16397]
debase/base to-hex 255 16
BrianH
19-Apr-2010
[16398x2]
To do proper integer to binary conversions in R2 you can convert 
the individual octets of the integer to char and then convert them 
to binary. I'm sure Steeve has more solutions for that though.
As he proved while I was waiting for the post to arrive :)
Pekr
19-Apr-2010
[16400]
thanks .... will try to mess with it. The bug in R3 preventing to 
join binarries is really bad ...
BrianH
19-Apr-2010
[16401]
I just mentioned it in the a98 call for fixes blog.
Pekr
19-Apr-2010
[16402]
ok, thanks. Hopefully Carl notices it ....
BrianH
19-Apr-2010
[16403x2]
I really hope we go through the CureCode tickets soon and collect 
all of the ones that make minor changes to core semantics, so we 
can do a rip-the-bandaid-off fix-them-all release soon. Before too 
much code is written that might depend on the unfixed behavior.
Not a98 though - we don't want to delay the new extension model.
Pekr
19-Apr-2010
[16405]
it depends on Carl. I hope we get to more frequent R3 releases again. 
And - A98 will contain only partial Extension model implementation 
...
BrianH
19-Apr-2010
[16406]
Yes, but enough to get the code into the hands of testers that can 
work out the kinks.
Ashley
19-Apr-2010
[16407]
re:Python's operators. I've always liked AutoIT's assignment operators, 
some of which (especially concatenantion) would be quite useful in 
REBOL.

	=	Assignment. e.g. $var = 5ΚΚΚΚ (assigns the number 5 to $var)
	+=	Addition assignment. e.g. $var += 1 ΚΚΚ (adds 1 to $var)
	-=	Subtraction assignment.
	*=	Multiplication assignment.
	/=	Division assignment.

 &=	Concatenation assignment.Κ e.g. $var = "one", and then $var &= 
 10ΚΚΚ ($var now equals "one10")
Anton
19-Apr-2010
[16408]
Except for the concatenation, these are C language operators.
BrianH
19-Apr-2010
[16409x2]
These make sense in C or Python syntax, or other languages where 
assignment is a syntax thing, but I'm not sure that it works that 
well with a language with word values, and assignment that doesn't 
use =. I don't see how they'd fit in REBOL syntax. That is not to 
say that the functions that these operators represent wouldn't be 
useful to have - just that they would fit in better in prefix form. 
Just an opinion though.
We have &= already though, it's called APPEND.
Ashley
19-Apr-2010
[16411]
As long as the first argument is a series ...
BrianH
20-Apr-2010
[16412x2]
All of the operators above are modifying, and the only things you 
can concatenate to in R3 are supported by APPEND. So yeah.
Series, or map or object.
Maxim
23-Apr-2010
[16414x5]
is there a function which looks like find but return true here:

Type desktop to start the Viewtop.
>> a: ["111" "222" "111"]
== ["111" "222" "111"]
>> b: a/3
== "111"
>> same? find a b b
== false
otherwise this HAS to be added to R3
something like FIND/EXACT
or even better  FIND/SAME
it would also be a hell of a lot faster  :-D
Ladislav
23-Apr-2010
[16419]
no native of this kind is available yet AFAIK
Pekr
23-Apr-2010
[16420]
or index? being extended, to return you a pointer to the originating 
series? But such information might not be available to interpreter 
after the assignment?
Ladislav
23-Apr-2010
[16421]
(but I wrote a corresponding function to the Identity articticle)
Maxim
23-Apr-2010
[16422x2]
its a shame cause looping a large list manually and comparing with 
same?  is VERY slow  :-(

on a 10 million sized series. 


my fastest FIND-SAME loop is 20 time slower than FIND, which would 
be much faster, since all it would have to do is compare a pointer.
did you time it vs find?  maybe its faster than mine?
Ladislav
23-Apr-2010
[16424]
No way, I did not optimize for speed
Steeve
23-Apr-2010
[16425]
can't you wrap the items of the list inside objects ?
In that case, it will be a find/same
Maxim
23-Apr-2010
[16426x2]
here's my fastest one yet... I tried two so far...

	;-----------------
	;-     find-same()
	;-----------------
	find-same: func [
		series [block!]
		item [series! object!]
		/local s i
	][
		i: 1
		repeat s series [
			i: i + 1
			if same? s item [
				break
			]
		]
		unless i > length? series [
			at series i - 1
		]
	]
	

using until was slower probably because REPEAT is faster than UNTIL 
(no exit condition or series index to increase).
steeve no... its a database like flast list of labels with corresponding 
data items.
Steeve
23-Apr-2010
[16428]
Hey it's your choice, nothing is unchangeable :-)
Maxim
23-Apr-2010
[16429x2]
its for the list style... hehe would you rather do

fill my-list/aspects/list ["Steeve" 1 "Max" 2 "Lad" 3] 

or


fill my-list/aspects/list reduce [context [label: "Steeve" data: 
1] context [label: "Max" data: 2] context [label: "Lad" data: 3]]
note the multi-column list will use the same data interface


IMHO it gets even less fun if you are using DB queries to populate 
the list.


it also generates a lot of useless & SLOW binding everytime you change 
the list
sqlab
23-Apr-2010
[16431]
How about combining find with a loop
find-same: func [
	series [block!]
	item [series! ]
	/local s 
][
	while [s: find series item] [
		if same? first s item [return  true]
		series: next s
	]
	false
]
Maxim
23-Apr-2010
[16432x3]
that's a hell of good a idea  :-)
thanks why didn't I think of that

to close to the tree to see the forest   :-/
yep much faster.   :-)


still /SAME has to be added to FIND.  the search would be almost 
instantaneous (Relatively speaking, of course) if done natively.