lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, Jan 17, 2019 at 8:45 AM Dirk Laurie wrote:
This is just disguised version of hardy perennial on this list:
(a) relying on equality testing involving floating-point arithmetic
(b) blaming Lua when it does not work as expected.
But all this will still not solve the problem that the following loop
does not work as expected:
> for k=1,2,1/6 do print(k) end

IMO, this loop works "as expected".
6*(1/6) ~= 1, and everybody reading this list is aware of it  ;-)
Float-comparison is a red herring which prevents you from seeing the main idea of the post.
I assume that user knows EVERYTHING about Lua numeric datatypes (floats, integers).
But anyway, Lua could make a surprise due to weird internal logic of numeric "for"-loop.

But it actually makes matters worse that the objectionable behaviour
is not an implementation detail but part of the specification.

This strange behavior should not be a part of the language specification!
My suggestion is to add some more LOC in Lua source and make numeric "for"-loop more correct.
"More correct" means "to satisfy user's expectations more closely".
For example, the loop "for x = N, N do" should work correctly whatever N is, including the case N==math.huge

Put all the clever tricks in a function 'loop' and use the generic for:
   for v in loop(e1,e2,e3) do

It's too slow (to call a Lua function on every iteration).