World: r3wp

Carl (or Gabriele), is that formula you gave for LOG-2 the way it 
is implemented in the LOG-2 native? I thought a binary logarithm 
would have a more efficient implementation on a binary machine.

I've been using it to calculate IP subnets and the like.

binary logarithm: you can spare one multiplication, that doesn't 
look like a big difference

Remembering the constant could be :(

I do not understand

do you mean that it is a problem for you to remember the constant?

Still, it would surprise me if that is how C has to calculate a binary 
logarithm. I thought there'd be an instruction or something. Spoiled 
by CISC processors I suppose.

Actually, there is a lot of things I have to remember and adding 
long numeric constants to the list would be a problem. That isn't 
sufficient justification (to me) to add another opcode. Greater efficiency 
would be, as would making the log-* set as complete as REBOL's natives 
are to save on silly questions like mine in the future :)

(Another thing to remember: Grammar-check my posts - I can't fix 
them later)

you don't have to remember it...

log-e 2

>> log-e 2
== 0.693147180559945

See, that solves one problem.

log base b (x) = log (x) / log (b)

I still think the native version would be more efficient than that. 
Base-2 logs help a lot with binary to decimal conversion (or was 
it vice-versa?). I may be wrong here though...

one opcode more or less should not be the difference,no? So why not 
to add it if found usefull? :-)

Wasn't there a log2 instruction in x86 before the floating-point 
processor was incorporated onto the main chip?

Floating point division on x86 is quite slow in comparison to integer 
operations, sometimes more than 10 times as slow.

(depending on the cpu)

and log2 does help with it? Just asking - most of the time I dunno 
what you are talking about here :-)

you don't have to use division: (log-2 x) = (log-e x) * (log-2 e)

They used division in their above solution.

Adding a mul instead of a div isn't such a big deal, in comparison.

I think, that everyone knows, that division by a constant can be 
replaced multiplication by its reciprocal, which is a constant too 
:-)

So your example would be (log-2 x) = (log-e x) * (1 / (log-e 2))

especially since e isn't defined as a constant in REBOL, and log-2 
isn't a rebcode opcode so we can't use it here.

of course you can, just define: log-2e: log-2 e

log-2e: log-2 exp 1

Ah, exp 1. It has been a while, I had forgotten.

actually, it may be of a value to have: e: exp 1

I suppose those "constants" could be calculated ahead of time and 
just inserted in the code as local variables. Well, that solves the 
functionality and memory (mine) problems. Still, it seems like C 
libraries and such must have a better way of doing this - it seems 
a bit inefficient.

On a binary machine, wouldn't log-e and log-10 be implemented on 
a lower level on top of log-2, instead of the other way around?

I'm probably just misunderstanding logarithms.

i don't think there's any way to implement log-2 any faster then 
log-e

On a binary machine, wouldn't log-e and log-10 be implemented on 
a lower level on top of log-2, instead of the other way around?
 not exactly, it is a kind of a "mix" AFAICT

see http://en.wikipedia.org/wiki/Natural_logarithm

log-2 (and 8, 16, etc) should just be bit shifting and "bit-tabling" 
since 2 is a "natural number" in computers....no "Math" needed...;-)

only if you want just integer part of the result, though

otherwise you really need some multiplication

(which is a bit shifting etc. too ;-)

Do you think anything like following would be possible? (simply trying 
to get some real-life example usability of rebcode, e.g rewriting 
some mezzanines). Some time ago, we've got 'remove-each. But initially 
there was not any such function available ... so I wanted to filter 
directory listing - it was rather slow in rebol, untill remove-each 
appeared. I would like to teas rebol level vs native vs rebcode. 
Could such functionality be achieved in rebcode? I mean - take a 
block, traverse it, remove each element where last char is #"/"?

Steve: but you need a loop! so, unless you have that in hardware 
(and it still doesn't seem doable to me for floating point), log-e 
will be easier to compute (see wikipedia article)

petr: PARSE is probably going to be much faster than rebcode for 
something like that, IMHO. after all, PARSE is a specialized virtual 
machine.

the REMOVE-EACH success is based on a better algorithm. It is possible 
to implement a pure REBOL mezzanine doing much better than a "dummy 
approach does"

...as well as you may be able to implement a C algorithm doing worse 
than a proper REBOL approach can do

Gabriele - thanks for the idea with parse and the note about it being 
a VM of some kind .... now I get it a little bit better :-)

we currently have insert, copy, do you think 'find would make sense? 
It is like moving in loop till some char :-) well, could be done 
in rebcode itself or so it seems :-)

apply result find [series value]   :-)

Brian: it's confirmed, BRAW takes a relative offset like BRA.

Ladislav, looking back on the code I've written in REBOL using logarithms, 
it turns out that the integer part of log-2 was all I was interested 
in. Apparently I have just been using it to find out how many bits 
are needed to hold a particular integer value when I've needed such 
info. I haven't used logarithms for regular computation since I was 
in grade school. Oh well, I guess I'm not the target market for the 
log-* functions. Thanks for the link, it's been interesting reading!

Gabriele, a relative offset. Darn. That is going to make BRAW a lot 
more difficult to use for me. What kind of programming tasks are 
made easier with a relative computed goto?