![]() |
|
Do you know where your variables are? | |
PerlMonks |
Re^6: Fold a list using map splicesby Aristotle (Chancellor) |
on Sep 04, 2004 at 03:01 UTC ( #388475=note: print w/replies, xml ) | Need Help?? |
I'm not sure why I used splice where I could have used unshift. Probably for the same reason you used it instead of push — too fixated on splicing. :-) You misunderstood the purpose of the padding in my code, btw. Remember that I splice before invoking the callback — which means that without padding, I'd be throwing away the values that should have been processed in the first iteration. I'm unsure what kind of pretzel logic led me to that solution, I should simply have used the list returned from splice.
One thing about your solution that irks me since my days as an assembler programmer is multiplying a constant with a counter in a loop. You get the same effect if you simply iteratively add the constant to a counter. Of course, it doesn't make a particular difference in efficiency in Perl, but I find that it can still improve clarity and reduce repetition to do it that way.
As well, the non-padding case can be dealth with less cumbersomely than my and BrowserUk's previous attempts do, which rely on that really ugly ternary. The splicing flavour (see 2nd update):
Analogously, the index-based flavour:
I think I'd still prefer the splicing version. Update: the index-based flavour had $n = $#_ - $i if $i + $n > $#_; which is an off-by-one error, since the range goes to ( $j += $n ) - 1. It has indeed got to be completely analogous to the splicing flavour, using @_ instead. Fixed. Update: I am amused at myself. The "padding" splicing version actually didn't pad, because splice, of course, only returns as many elements as there are left, if you ask for more. The padding version turns out to be much simpler than the "non-padding" version I concocted before — no special cases at all!
This is Perl as I love it. Beautiful and simple. :-) Makeshifts last the longest.
In Section
Snippets Section
|
|