World: r3wp

The particular thing to note here is that the
    if (test)

is the entire clause. It depends on the parse dialect's own flow 
control to tell where to go next, not some passed block.

Thanks Graham! According to the internet archive, the page was started 
in March, 2000 and was taken down after Dec, 2003.

The last version of this page is http://web.archive.org/web/20021209120704/www.robertmuench.de/parse_ideas.html

I am referenced twice in this page under different, outdated email 
addresses.

then I think, that your suggestion is exactly like mine...

(as opposed to Gabriele's proposal, that is different)

May I ask you to put it to RAMBO?

(both USE and IF look worth it, maybe you can have each in its own 
ticket?)

Would it be nice to have the raised to exponent (**) operation in 
rebcode? And with decimal exponent. Maybe we should ask Carl about 
that before the first version is closed? Maybe also root operation? 
(Not just square-root, as we already have.)

a ** b can be "translated" as follows:

log-e a
muld a b
exp a

similarly root:

log-e a
divd a b
exp a

;this is probably key rebcode if you want to deal with colors of 
image pixels:)
rgb-to-dec: rebcode[r g b][
	to-dec r r
	to-dec g g
	to-dec b b
	muld g 256.0
	muld r 65536.0
	addd b g
	addd b r
	return b
]

and alpha? :-)

rgba-to-int: rebcode[r g b a][
	to-dec r r
	to-dec g g
	to-dec b b
	to-dec a a
	muld g 256.0
	muld r 65536.0
	muld a 16777216.0
	addd b g
	addd b r
	addd b a
	to-int b b
	return b
]

Thanks Ladislav! Been a while since I learned about the math. I can 
cope with it using those 3 operations instead of exponent or root.

Oldes, I think this is a bit faster ;)
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	add a r
	add a g
	add a b
	return a
]

Cyphre, use OR instead of ADD and there will be no troubles with 
arithmetic overflow. It'll be faster too.

I think there shouldn't be aritmetic overflows as the passed arguments 
are meant within range 0-255 but you are right that OR should be 
even faster!

so probably final version:
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

There might be a problem with arithmetic overflow if a < 127, as 
lsl a 24 would result in a negative integer, but I may be wrong here. 
Still, why risk it?

>> rgba-to-int 255 255 255 255
== -1

Kru, which version did you use?

last one

Cool, it works the way I thought it would :)

BTW negative integer doesn't  matter when changing pixels in IMAGE!

>> to-integer to-binary  255.255.255.255
== -1

but to integer! to binary! [issue!] is not same as rgba-to-int

OTOH the pixelformat of accesing IMAGE! in RebCode id ARGB

>> rgba-to-int 255 255 255 1
== 33554431
>> to-integer to binary! 255.255.255.1
== -255

>> to-integer to-binary  1.255.255.255
== 33554431

ALPHA is the first component

(in Rebcode)

Really?

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	poke img 1 a
]

update-pixel: does [
	do draw-pix col/1 col/2 col/3 col/4
	probe img
	show i
]

col: 0.0.0.0
img: make image! 1x1

view layout [
	backcolor black
	i: image img 100x100
	scroller 200x16 [
		col/1: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/2: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/3: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/4: to-integer face/data * 255
		update-pixel
	]
]

not if you do PICK on image!

I mean in regular REBOL code.

I guess Cyphre has a good qualification for such statements ;)

I REBOL the pixelformat is RGBA due to tuple! behaviour (you can 
left the last value of tupple == opaque pixel)

So another coversion needed :)

In REBCODE you are accessing image! internally so the pixelformat 
is ARGB.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

Cypher, have you looked at the apply problem?

not yet

There's an apply problem?

trying to reproduce the problem I've just crashed REBOL with CRASH 
Should not happen

Maybe not a problem, but overhead?

And REBOL ate all memory

can you post the code?

yes, show us!

two testing functions:

>> mulr: rebcode [a][mul a 2 return a]
>> mull: rebcode [a][loop 10000000 [apply a mulr [a]] return a]

From my tests calling a REBCODE function (or subroutine) using APPLY 
is by 100% slower than reusing the same code.

first test: xt: now/time/precise loop 10000000 [mulr 2] now/time/precise 
- xt