[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Possible bug with the length operator
- From: Eduardo Ochs <eduardoochs@...>
- Date: Sun, 3 Apr 2011 05:22:01 -0300
On Fri, Apr 1, 2011 at 11:03 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> Maybe we could collectively have a friendly, instructive standard
>> answer ready?
>
> My standard answer (not sure whether it is instructive) is that there is
> no good *meaning* for #t when t has holes. What should be the results
> of the following expressions?
>
> #{[1000] = 1}
> #{1, nil, 3, 4, 5, 6}
> #{1, 2, nil, 4}
> #{[4] = 4, 1, 2}
> #{1, 2, 3, nil, 4, nil, nil}
> #{1, 2, 3; x = 4}
> t = {1, 2, 3, 4}; t[4] = nil; print(#t)
> t = {1, 2, 3}; t[4] = nil; print(#t)
>
> How useful would be these results?
>
>
> To simply solve the non-determinism problem, there are at least the
> following options:
>
> 1 - the number of numeric (integer?) keys
> 2 - the total number of keys
> 3 - the largest numeric (integer?) key
> 4 - the smallest integer key k such that all keys 1..k are present
>
> For a table without holes, all options are equal except 2. Otherwise,
> all options are (always?) different.
>
> All options solve the non-determinism of the current #t, but none solves
> the real problem of how to give the "length" of a list with holes. (2
> may fail even for tables without holes, if the list is mixed with other
> non-numeric keys.) Each will be useful in a few particular cases, but
> none is generic.
>
> So, a really cheap way to implement 1, 3 or 4 would be welcome, mostly
> to improve the documentation. But it should be really cheap, because
> it does not solve the real problem anyway. ("really cheap" means
> zero memory overhead for tables + zero overhead for table access +
> sublinear time for # + very small overhead for table updates + simple
> implementation.)
>
> -- Roberto
An idea: use "or" (and "is", and English). So:
#{[1]=1,[2]=1,[4]=1,[8]=1,[16]=1,[32]=1,[64]=1,[128]=1}
is 2 or 4 or 8 or 16 or 32 or 64 or 128
#{[1000] = 1} is 0 or 1000
#{1, nil, 3, 4, 5, 6} is 1 or 6
#{1, 2, nil, 4} is 2 or 4
#{[4]=4, 1, 2} is 2 or 4
#{1, 2, 3, nil, 4, nil, nil} is 3 or 5
#{1, 2, 3, x=4} is 3
#{1, 2, 3, [4]=4, [4]=nil} is 3
#{1, 2, 3, nil} is 3
Note that this proposal is related to the one in
<http://lua-users.org/lists/lua-l/2011-02/msg01467.html>. There I
defined "vlists" to cope with a certain recurring conceptual problem;
here I am proposing a simple way to deal - in English - with the
non-determinism of the definition of "#" in
<http://www.lua.org/manual/5.1/manual.html#2.5.5>. I think that the
use of an "or" in such contexts is sufficiently striking to make
people think about it and understand what is going on.
Cheers,
Eduardo Ochs
eduardoochs@gmail.com
http://angg.twu.net/