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

World: r3wp

[rebcode] Rebcode discussion

BrianH
14-Oct-2005
[237x4]
They can be a great way to speed up state machines, implement switch 
statements and such.
(I mean C-style switch statements)
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.
Ladislav
14-Oct-2005
[241]
binary logarithm: you can spare one multiplication, that doesn't 
look like a big difference
BrianH
14-Oct-2005
[242]
Remembering the constant could be :(
Ladislav
14-Oct-2005
[243x2]
I do not understand
do you mean that it is a problem for you to remember the constant?
BrianH
14-Oct-2005
[245x3]
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)
Gabriele
14-Oct-2005
[248x3]
you don't have to remember it...
log-e 2
>> log-e 2
== 0.693147180559945
BrianH
14-Oct-2005
[251]
See, that solves one problem.
Gabriele
14-Oct-2005
[252]
log base b (x) = log (x) / log (b)
BrianH
14-Oct-2005
[253]
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...
Pekr
14-Oct-2005
[254]
one opcode more or less should not be the difference,no? So why not 
to add it if found usefull? :-)
BrianH
14-Oct-2005
[255x3]
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)
Pekr
14-Oct-2005
[258]
and log2 does help with it? Just asking - most of the time I dunno 
what you are talking about here :-)
Ladislav
14-Oct-2005
[259]
you don't have to use division: (log-2 x) = (log-e x) * (log-2 e)
BrianH
14-Oct-2005
[260x2]
They used division in their above solution.
Adding a mul instead of a div isn't such a big deal, in comparison.
Ladislav
14-Oct-2005
[262]
I think, that everyone knows, that division by a constant can be 
replaced multiplication by its reciprocal, which is a constant too 
:-)
BrianH
14-Oct-2005
[263]
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.
Ladislav
14-Oct-2005
[264x2]
of course you can, just define: log-2e: log-2 e
log-2e: log-2 exp 1
BrianH
14-Oct-2005
[266]
Ah, exp 1. It has been a while, I had forgotten.
Ladislav
14-Oct-2005
[267]
actually, it may be of a value to have: e: exp 1
BrianH
14-Oct-2005
[268x3]
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.
Gabriele
14-Oct-2005
[271]
i don't think there's any way to implement log-2 any faster then 
log-e
Ladislav
14-Oct-2005
[272x2]
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
eFishAnt
14-Oct-2005
[274]
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...;-)
Ladislav
14-Oct-2005
[275x3]
only if you want just integer part of the result, though
otherwise you really need some multiplication
(which is a bit shifting etc. too ;-)
Pekr
14-Oct-2005
[278]
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 #"/"?
Gabriele
14-Oct-2005
[279x2]
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.
Ladislav
14-Oct-2005
[281x2]
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
Pekr
14-Oct-2005
[283x2]
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 :-)
Gabriele
14-Oct-2005
[285x2]
apply result find [series value]   :-)
Brian: it's confirmed, BRAW takes a relative offset like BRA.