From: "Mauricio Fernández" <batsman.geo@...>
Date: 2003-07-23T18:31:10+09:00
Subject: Re: A different Version of Enumerable#inject

On Wed, Jul 23, 2003 at 06:03:08PM +0900, Robert Klemme wrote:
> 
> Apparently the other post got overlooked - and it had an error in the
> implementation.  What do others think of this suggestion of a changed
> Enumerable#inject that uses a sliding window whose size is determined by
> the block's arity.

I tend to dislike #inject cause it's almost always more complex than
using #each + the needed logic (and slower too), as it's providing the
wrong sort of abstraction in many cases (gets further away from the
problem domain, not closer, IMHO). To put it another way, #inject
represents a movement orthogonal to the "complexity line of force".

However, your extended #inject seems OK to me, because of the sliding
window concept. Now *that* is something useful in some cases, and using
your #inject means I don't have to propagate values.

I would like it to become common, as it's probably the only kind of
#inject I would like to use :-)

> # integration
> enum.inject([]) {|m,x,y|m<<(x+y).to_f/2}

Is this really integrating? It won't give the same results as
m = []
enum.each{ |x| m << (m[-1]||0) + x }

will it?

If I understand what your #inject does, this is only averaging pair-wise.
(too lazy to read your code now :-)

> # weighted integration
> enum.inject([]) {|m,x,y,z|m<<(x+y+y+z).to_f/4}

you mean a convolution with [0.25, 0.5, 0.25], no?

Convolution probably deserves a method on its own, but I don't think
Enumerable#convolution is going to be really used anyway :-)

-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Turn right here. No! NO! The OTHER right!