Can someone explain exactly what this code is doing? I'm confused by
this usage of ":" and its relationship to a block.
[EMAIL PROTECTED] wrote:
> Thanks Renaud,
>
> <Renaud>
> MultiplyBlocks: func [
> Block1 Block2
> /local sum
> ][
> sum: 0
> repeat i min length? Block1 length? Block2 [
> sum: sum + (Block1/:i * Block2/:i)
> ]
> return sum
> ]
> </Renaud>
>
> What was missing from my knowledge was how to reference a block using a
> variable (pardon my non-Rebol terminology) ..... When I'd tried things like
> Block1/Ind I got told that was a bad path. Your little colon makes all the
> difference.
>
> <Renaud>
> Note that you don't need to explicitly use RETURN in your functions, since
> the last value of the affectation is still available when Rebol exits the
> loop.
> </Renaud>
>
> True for MultiplyBlocks1. But MultiplyBlocks2 does need an explicit return,
> at least on my machine. And, maybe it's a matter of style, but I'd rather
> have an explicit return: it helps a stranger's eye when looking at code. It
> also means I can add debugging code without breaking assumptions.
>
> <Renaud>
> It's also interesting to notice the relative speed of each
> function (multiply 2 blocks of 15 integers):
> <snip>
> </Renaud>
>
> I've changed my code to your "block/:i" format. It knocks 15% of the
> application run time. A worthwhile improvement indeed.
>
> <Brett>
> Next option would be to use Ladislav's %highfun.r script
> (http://www.rebol.org/advanced/index.html). There you will find functions
> that will make this work more elegant, or a technique to make the functions
> I've shown more generic.
> </Brett>
>
> Thanks for this reference. I certainly don't want to spend my life
> reinventing the wheel, and especially not clunky wheels
>
>
> <Michael>
> To write the most compact piece of code for performing this task one could
> split some hairs and chop out a few chars here and there, but that does not
> necessarily make it more readable/maintainable or better.
> </Michael>
>
> I wasn't trying to write the shortest possible code. But I like to think that
> I write code that is easy to follow. Which is why the PICKs and FIRSTs in my
> two samples niggled. They cluttered a function that ought to be simple. Call
> it programmer's intuition, but I knew there must be a better way. But my
> RTFMing skills had failed to find it.
>
>
> Thanks for all the help guys. I think I am beginning to get the hang of this
> language!
> Colin
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
