Re: Why no for table-iterator like e. g. "hashpairs"?

[bil til <flyer31@...>]

Hi Phillipe,
yes this is correct, very strictly spoken 3 would be correct for this
"random hole 1...1000 table".

The Lua code uses some fast exponential search algorithm which starts with
the current size of their table array part, and then goes to half, and half
again, and looks for points, were index i is still ok, and i+1 missing /
nil. (as 1000 is about 2^10, it needs only roughly 10 iterations so come to
some "senseful" value ... this is very efficient... it would only need
maximum about 32 such tries, if the table has a size of about 2GB... ).

Of course you can call this "crazy" ... but such a language of course always
has to find some compromise between time and the accuracy.

But what here mainly dseerves to be calles crazy, is of course this table
itself ... a table with "random holes" of course is something very fuzzy ...
and you can start discussing, whether for #t the value 3 (the max non-nil
index) here makes more sense, or 656 would make more sense (the number of
non-nils), so 440 might even be some sort of "crazy compromise for crazy
table / crazy conditions".

Seen from fy side this is fine.

I just think, that 99% of large table applications for "exhausting for
operations" will have 99% index part and only <1% hash part or even less.
And in this case in the current situation the iterators "pair" and "next"
behave extremely nasty to check the table hash part ... . They require to
walk through a complete huge key assembly of "boring numbers", only to get
then the link to this "hash side info" - which in case of tables of course
often IS crucial... . 

For loops in non-JIT interpreter languages anyway always are quite a waste
of time, and I think that an interpreter language always should support the
programmer as good as possible to avoid "hanging around in for loops"
unnecessarily.

(I did not look in detail at luaJIT yet (and I am not really interested in
this, as my applications concentrate on low resource (ROM/RAM) consumption
and flexibility... there lua I think is VERY optimum...), but I am quite
sure that all these examples from the luaJIT homepage where they state to
have 20-100 times speed increase, will be some "crazy for loop number
crunching" applications ... you could of course also try to do gigantic
table crunching in lua, like jpeg compression or so, but this no normal
person would try usualy in an interpreter language as lua I think ... just
anyway for loops ARE of course anyway very important for lfexibility).





--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html