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

World: r3wp

[Rebol School] Rebol School

BrianH
16-Mar-2010
[3030x3]
And it wouldn't work with EXIT, since the dynamically scoped version 
of the function wouldn't be able to call the definitionally scoped 
RETURN. The whole section gives the impression of not being thought 
through. And we're in the wrong group for this discussion.
Easy to bind, the word is in the spec block.
, "Extra value on function frame." It doesn't mention two values.
It doesn't matter though - I'm sure whatever we all decide on will 
be fine.
Ladislav
16-Mar-2010
[3033x2]
Just a note, which may as well be put here, I guess: since R2, Rebol 
"mixes" definitionally scoped and dynamic constucts, and it looks, 
that this mix will stay with us even in R3
(but, of course, the proportions may change)
Gabriele
16-Mar-2010
[3035]
I understood Carl's proposal in the same way as Ladislav...
Andreas
16-Mar-2010
[3036]
So did I ...
BrianH
16-Mar-2010
[3037]
Continuing in the right group...
Janko
20-Mar-2010
[3038]
is there any word that would let me join two objects together?
Henrik
20-Mar-2010
[3039]
make obj1 obj2
Janko
20-Mar-2010
[3040x3]
aha.. I can just use multiple make
or what you said.. even better in my case
cool things :)
Henrik
20-Mar-2010
[3043]
it creates a new object, though. in R3, you can use the extend function 
to extend an existing object with one new value.
Steeve
20-Mar-2010
[3044]
extend does not do that (though it could, just a mezz).
but this do it:
>> append obj1 body-of obj2
Henrik
20-Mar-2010
[3045]
extend extends with a single value, where append can extend with 
any values.
Davide
21-Mar-2010
[3046]
Just for fun (it's a slow sunday today) I've wrote a rebol version 
of the code used as benchmark in this page http://tinyurl.com/5nezt9

here's the code:

REBOL []

person: make object! [
	_count: none
	_prev: none
	_next: none
	
	_construct: func [n] [_count: n]
	get-prev: does [_prev]
	set-prev: func [pr] [_prev: pr]
	get-next: does [_next]
	set-next: func [nxt] [_next: nxt]
	shout: func [shout nth /local aux] [
		if shout < nth [
			return shout + 1
		]
		aux: get-prev aux/set-next get-next
		aux: get-next aux/set-prev get-prev
		1		
	]
]

chain: make object! [
	
	_first: none
	_last: none
	
	_construct: func [size /local current] [
		repeat i size [
			current: make person []
			current/_construct i
			if none? _first [_first: current]
			if not none? _last [
				_last/set-next current
				current/set-prev _last 
			]
			_last: current
		]
		_first/set-prev _last
		_last/set-next _first
	]
	
	kill: func [nth /local current shout] [
		current: _first
		shout: 1
		while [not equal? current current/get-next] [
			shout: current/shout shout nth
			current: current/get-next
		]
		_first: current		
	]	
]

start: now/precise
iter: 100000
loop iter [
	current-chain: make chain []
	current-chain/_construct 40
	current-chain/kill 3
]

print ["Time per iteration =" (difference now/precise start) / iter 
]
halt

which give me:
Time per iteration = 0:00:00.00080234

802 microsecond that is the slower time of the benchmark, 

but not SO slow, php is near with 593 microsecond, jython 632 ... 
.(the test system is pretty like mine so i can compare the result)

There's a way to improve the performance?
Henrik
21-Mar-2010
[3047]
if not = unless

also perhaps:

if none? _first [_first: current] = any [_first _first: current]

not equal? = not-equal?

Didn't check if there are some mezzanines in there, though.
Davide
21-Mar-2010
[3048]
a bit better:
Time per iteration = 0:00:00.00077844
Henrik
21-Mar-2010
[3049x2]
any instance of IF can possibly be replaced by ANY or ALL.
get-prev: does [_prev]
set-prev: func [pr] [_prev: pr]
get-next: does [_next]
set-next: func [nxt] [_next: nxt]


These will also slow things down. I'm not sure if you can get rid 
of them.
Pekr
21-Mar-2010
[3051]
jython? So python version emulated in JAVA is faster than native 
REBOL? :-)
Henrik
21-Mar-2010
[3052]
Davide, try an R3 version too.
Davide
21-Mar-2010
[3053x3]
java is in the class of c++ in performance AFAIK

I remember the in 1998 there was a mame - java applet that could 
run phoenix at 100% of the velocity with no skipframe (I had a pentium 
100 Mhz at that time)
using _prev and _next instead of function the result is:
Time per iteration = 0:00:00.00056687
with R3:
Time per iteration = 0:00:00.00034359
Geomol
21-Mar-2010
[3056]
I don't think, Java is as C++ in performace. C++ can be compared 
to C in performace, and Java is at least 8 times slower. See e.g.:
http://www.timestretch.com/FractalBenchmark.html
Henrik
21-Mar-2010
[3057]
R3 performance: Interesting. :-)
Davide
21-Mar-2010
[3058]
Yes, I meant in the same class if compared to ruby, python or similar.

java is slower than c++ (but I think that 8x slower is not realistic 
in common usage)
Paul
21-Mar-2010
[3059]
David you can dump those mezzanines and just use make function! instead 
of 'does and 'func.  Maybe use the operators such as <> instead of 
not equal? and use chain assignment here and there were applicable.
Davide
21-Mar-2010
[3060]
a bit OT: yesterday I've discovered that compiled VB6 run as fast 
as tcc in number crunching :-)
Steeve
21-Mar-2010
[3061]
http://tinyurl.com/5nezt9,already dead ?
Davide
21-Mar-2010
[3062]
works here, the plain url is http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
BrianH
21-Mar-2010
[3063x2]
Java is faster than REBOL at Java-style code, because REBOL is optimized 
for a different code style. If you are writing code in REBOL style 
then it can be faster than Java in some cases, or at least less slower 
in other cases. In this case what is slowing down REBOL is all of 
the unnecessary accessor code: OO overhead that Java can optimize 
away, but it REBOL you just don't write in the first place.
On the other hand, you probably ran your tests on different hardware 
than he did, so time results may not be comparable :)
Janko
21-Mar-2010
[3065]
I know that rebol appeared to be the slowest language on debian language 
shootout , but then cheyenne is *much* faster webserver than any 
of the ones made in dynamic languages I tried (even lua). so speed 
is a relative thing it seems (like Brian says)
Henrik
21-Mar-2010
[3066]
also when using dialects, there is often a huge speed gain, but you 
can't really code like that in most other languages.
Davide
21-Mar-2010
[3067]
In this case, I think that  we can be happy with performance too.
Janko
13-Apr-2010
[3068]
Is there a way to pass a refinement further? so I don't have to do 
something like
do-some: func [ /ref ] [ either ref [ do-more/ref ] [ do-more ] ]
Ladislav
13-Apr-2010
[3069x2]
that is an oldie. In R3 as well as in R2+Rebcode you can use a native 
APPLY
otherwise you are mostly "out of luck"
Janko
13-Apr-2010
[3071]
aha, my r2 doesn't seem to have apply.. I will solve it some other 
way :) thanks
Ladislav
13-Apr-2010
[3072x2]
Well, the mezz. Apply may be quite slow, but if it suffices...
Then you can download it somewhere
Janko
13-Apr-2010
[3074]
I will use normal argument .. I don't want to further complicate 
codebase to make it a little nicer
Ladislav
13-Apr-2010
[3075]
http://www.rebol.org/view-script.r?script=apply.r
BrianH
14-Apr-2010
[3076]
There's an APPLY in R2/Forward that replicates R3's APPLY native. 
Either the native or the R2/Forward version will be in 2.7.8.
Maxim
14-Apr-2010
[3077x2]
janko, when I have chained calls which use options, I do this:

func [/opta /optb /options oblk][ 
	oblk: any [oblk copy [ ] ]
	if opta [append oblk 'opta]
	if optb [append oblk 'optb]

	; then use the block exclusively using find.
	if find oblk 'opta [print "option A supplied"
	if find oblk 'optb [print "option B supplied"

	; this way you can easily chain options 
	do-something/options oblk
]
oops... missing end "]" chars ... you know where.
Gregg
14-Apr-2010
[3079]
I've done the same thing as Max, and if there is just one refinement, 
I'll still use EITHER. If you have a scenario where there's an entry 
point that delegates work and requires multiple options, consider 
making it a dialected func.