Not too difficult...
the function take 2 blocs of numbers, say [2 3 4] and [3 4 5 6], and return
the sum of the corresponding terms in each bloc, i.e. : 2*3 + 3*4 +4*5 +
(0)*6
the code :
repeat i min length? Block1 length? Block2 [...]
is used to loop i from 1 to the size of the smaller block, and then :
Block1/:i is similar to "pick Bloc1 i", and so is looped as Bloc1/1
when i=1, Block1/2 when i=2 and so on...
Hope that answer to your question ;-)
Renaud
----- Original Message -----
From: "Harold Grovesteen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 07, 2001 4:16 PM
Subject: [REBOL] Re: Clunky-looking code
> 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.
>
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
