[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- 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)