World: r3wp

guys, how well does parse play with rebcode? It was said that parse 
is VM in itself, it is very right, but now we have some discussion 
about zlib support. Let's suppose we have rebol version on rebol.org 
and that we would like to speed it up. We can simple extend the idea 
to any other datatype (= in amiga terms, simply a file format, or 
protocol one). you will surely want to use parse. The question is, 
if you can speed up some things using rebcode?

Imagine e.g. doing image loader/saver ....

Kru, I calculate apply/power to be 5% faster than inline rebcode 
exponential function in my case. So I find:

apply/power is fastest, then
inline rebcode exponential, then
apply/REBOL function, then
apply/rebcode function

, when it comes to exponential function in my case.

Geomol can I see your test code?

Kru, I write it to you privately...

Using APPLY with POWER may be a special case, because the equivalent 
is 10-11 lines of rebcode. So in this case, calling POWER with APPLY 
is actually faster than programming the POWER function inline in 
rebcode. (I hope, I make sense.)

I also find
apply result power [b x]
to be faster than
do result [b ** x]

Correction:
power 0.0 0.0

gives result 0.0. I check for that in my code and give result 1.0. 
With that check before calling POWER, the inline rebcode version 
becomes the fastest, *not* apply/power

With rebcode, optimization suddently becomes science.

Wow! Making the factorial inline speeded it up 245%!
New bezier:

bezier: rebcode [
	t	[decimal!]
	P	[block!]
	/local result m n n! i a b c d idx
][
	do result [copy [0.0 0.0]]
	length? n P
	div n 2
	set m n
	sub n 1
	;apply n! factorial [n]
	set n! 1
	repeat x n [
		mul n! x
	]
	repeatz i m [
		to-dec a n!
		;apply b factorial [i]
		set b 1
		repeat x i [
			mul b x
		]
		to-dec b b
		divd a b
		set b n
		sub b i
		;apply c factorial [b]
		set c 1
		repeat x b [
			mul c x
		]
		to-dec c c
		divd a c

		eq i 0
		braf i-not-0
		set d 1.0
		bra muld-d-a
		label i-not-0
		to-dec c i
		set d t
		;apply d power [t c]
		log-e d
		muld d c
		exp d

		label muld-d-a
		muld d a
		set a 1.0
		subd a t

		eq b 0
		braf b-not-0
		set a 1.0
		bra muld-a-c
		label b-not-0
		to-dec b b
		;apply a power [a b]
		log-e a
		muld a b
		exp a

		label muld-a-c
		muld a d

		set idx i
		mul idx 2
		pickz b P idx
		muld b a
		pick c result 1
		addd b c
		poke result 1 b

		add idx 1
		pickz b P idx
		muld b a
		pick c result 2
		addd b c
		poke result 2 b
	]
	return result
]

how long would it take to calculate an image histogram?

ops, my last 2 messages should have been to Kru.

Pekr, with this histogram function:
histogram: rebcode [rgb result /local r n a b c] [
	length? n rgb
	div n 3
	repeatz i n [
		set a i
		mul a 3
		pickz b rgb a
		add a 1
		pickz c rgb a
		add b c
		add a 1
		pickz c rgb a
		add b c
		div b 3
		pickz c result b
		add c 1
		pokez result b c
	]
	return result
]

it takes 0.094 seconds on my machine to get histogram of 640x480 
pixel image.

0.406 seconds for 1280x1024 image.

You can try it like this:

img: make image! 1280x1024
result: copy []
loop img/size/x * img/size/y [insert tail result 0]
histogram img/rgb result

this code is not histogram:)

shouldn't histogram basically count pixels of 0- 255 channel values? 
:-)

yes

The histogram, I posted, count combined rgb values (or light value 
if you like). To count rgb values individually, a little change is 
needed.

(And you need more data structures to hold the results.)

I guess, Pekr's original question was about, if it's reasonable fast 
with rebcode, and I would say, that it is.

yes, thanks :-)

you know, when we originally developed high-end astronomy CCD camera, 
it returns you per-pixel value of 1 to 65535, according of how much 
current counts in the individual pixels ... you ten need to convert 
it to image, so you have to get minimu,maximum, and divide it into 
256 zones .... when I did it using plain rebol, it was painfully 
slow. Imagine having lucrative in-camera ethernet + ip, downloading 
image using rebol in 1 sec or so, and then waiting 19 secs tojust 
view the image :-) If we would do this device nowadays, with Rebcode, 
I believe I would not hesistate to use rebol for all operations ....

Was anybody testing if what is faster, if rebcode or c-code call 
using dll?

Right. I once talked with an astronomer working in Lund, Sweden. 
He told me about the software, they use. It's mostly based in code 
written in the 70'ies (in FORTH, if I remember correctly). It's good, 
well-tested software of course, but the user interfaces are terrible, 
often just a command-line. It could be interesting doing modern versions 
of some of that software using REBOL. But the scientists have to 
be 100% sure, the output is correct and the same as they get from 
the software, they use now. If the right function libraries were 
developed in REBOL (rebcode), I think scientists could be a good 
user-base (developer-base) for the REBOL language.

Geomol, they are probably using a domain specific language to drive 
their telescopes ... something forth pioneered.

They also use Forth to control the robotic arms on the space shuttles.

I think Rebol would be better for teachers than scientists, as in 
Rebol you can much more easily explore how programing works

Yeah, I would leave the scientists alone ... it's like trying to 
wean a unix user from their command line tools!

I live in command line with Rebol and I'm happy:)

these days telescope control should all be "ASCOM" compliant

http://ascom-standards.org/index.html

most of the stuff we met was crappy ...

even big SBIG used parallel port back in the time we used ethernet. 
The sad thing is - no money, no music ... 4 ppl working part-time 
can't beat 80 full-time workers. But we did, for ourselves - I have 
our camera in my table ;-) And we build quite a few telescopes - 
REBOL is COOL for astronomy - dialects etc. wow ... the thing is, 
if it would be adopted ....

pekr, did i understand that u were using rebol 4 astronomy? could 
show me/us some of ur worx? a collegue of mine - whom i really want 
to b converted from php to rebol - is an amateur astronomist and 
such a stuff can give him the final pulse to start learning&using 
rebol

jfyi i use forth regulary for writing pic microcontrolers applications 
(small ones usually)

tomorrow, or I will write to you privately, too tired now, time to 
sleep :-)

sure. thanks in advance!

Actually...
opcodes for integer math are :
	-add, mul, div, min, max, abs, ...
opcodes for decimal math are :
	-addd, muld, divd, mind, maxd, absd, ...

Would you prefer integer opcodes to be :
	-addi, muli, divi, mini, maxi, absi, ...
or not ?

(quick answer required!)

yes.

i typed it that way the first few times.

Speaking as someone who generates as well as wwrites rebcode, I would 
say yes. This frees up the non-typed opcodes to be rewritten with 
their typed equivalents by a type inferencer.

It also makes their typed nature explicit, and establishes the convention 
of <opcode>i for integer-specific opcodes, which will come in handy 
later when we add more (like picki/pokei).

Maybe it makes it sense to have generic math too, then we could add, 
sub etc too. Not sure, but if interaction with rebol is closer and 
we deal with rebol-created blocks?

would keep that option open.

Generic math is slower....

Yes, but a typecheck and a branch and a conversin even more.

I would prefer the explicit interger opcodes