• Subject: Re: Map and filter without intermediate tables
• From: Geoff Leyland <geoff_leyland@...>
• Date: Thu, 7 Jun 2012 23:06:51 +1200

```On 7/06/2012, at 10:13 PM, joao lobato wrote:

> FWIW, my experience with maps and filters and folds is that you don't
> really want them. If you have an array, use a numeric for. If you're
> iterating over the contents of an hash table, you're using it wrong.

Yes, but if you have a function generating a sequence and a series of sequence processors that might do things like map or filter that sequence, then you might consider avoiding intermediate tables, since there was never a table in the first place.

So you'd do a bit of benchmarking and find (modulo your messy implementation) that you might as well dump the sequence into a table and be done with it.

> There are too many alternatives. Take filter: you may want to apply
> the predicate to the keys or to the values; or maybe you want
> sequencial keys in the final sequence rather than the original keys.

In this case, I (think I) know the set of possible processors...

> In general, it is best just to write the for loop and be done with it.
> A 'for' with an 'if' is certainly much clearer than that 'repeat'.

... but information on the actual series of processors is not organised in a manner that makes writing the for loop straightforward.  (though I think it becomes easier if I use the intermediate tables)

I certainly agree that

a)
for i = 1, limit do
if i % 2 == 0 then
local v = i % 100
sum = sum + i + v * v
end
end

is nicer to look at than

b)
for i, vsquared in imap(ifilter(a, function(i) return i%2==0 end), function(v) return v*v end) do
sum = sum + i + vsquared
end

but things don't always work out that easy.  I'm also surprised that

c)
local t1 = {}
for i = 1, limit do t1[i] = i % 100 end
local j, t2 = 1, {}
for i = 1, #t1 do if i % 2 == 0 then t2[j] = t1[i]; j = j + 1 end end
local t3 = {}
for i = 1, #t2 do t3[i] = t2[i] * t2[i] end
local sum = 0
for i = 1, #t3 do sum = sum + i + t3[i] end

is one of the better implementations of b), and not *that* much worse than a)

```