Lua 5.3.5 Copyright (C) 19942018 Lua.org, PUCRio
> #5 stdin:1: attempt to get length of a number value stack traceback: stdin:1: in main chunk [C]: in ? > debug.setmetatable(0,{__len=math.abs}) 0 > #5 5 
On 5/7/19, 4:55 AM, "[hidden email] on behalf of Dirk Laurie" <[hidden email] on behalf of [hidden email]> wrote: Lua 5.3.5 Copyright (C) 19942018 Lua.org, PUCRio > #5 stdin:1: attempt to get length of a number value stack traceback: stdin:1: in main chunk [C]: in ? > debug.setmetatable(0,{__len=math.abs}) 0 > #5 5  I like to give your crazy ideas at least a few brain cycles before I check out, but I'm wondering where you're going with this. I don't think I know enough math, but do math people have opinions about how long a number is, before they take mushrooms? 
A problem this I can foresee, at least for variables, is that if fred is a number #fred will return the abs of that number. However if fred is a table then #fred will return it's length (with the usual caveats) I can envision a whole new class of errors where someone uses a scalar variable where they should have used a table and check the (supposed) tables length with the # only to find that it is not a table after all if #fred > 0 then print("We have " .. #fred .. " records to process") for k, v in pairs(fred) do print(k, v) end end Here the error is "bad argument #1 to 'for iterator' (table expected, got number)" Not sure that having an alias for abs is really worth the pain 
In reply to this post by Andrew Starks2
On Tue, May 7, 2019 at 10:01 AM Andrew Starks <[hidden email]> wrote:
There are multiple, contradictory interpretations of "how long a number is". They all boil down to "how many digits?" but there are conflicting ways of answering that question. How many digits are in 1? How many digits are in 1.00? How many digits are in 1e20? How many digits are in 0.001? Are we counting decimal digits? Binary digits? Bytes? Is there a difference between the length of a float and the length of an int? In the end the only answer that would be consistent would be to always return 8. /s/ Adam 
In my opinion the "length" of a number can only be the length of the string generated when converting this number to a string with the default string conversion. Note that keys in tables are not necessarily integers, they can be any number. It is an integer only to restrict tables to their sequence, but not all tables have a unique sequence, if there are "holes" such that there exists a integer key k in table t, where k >= 2, t[k] is not null, and t[k1] is null). Codes that expect sequences to give a meaning to "#t" cannot be portable if t is not a sequence with no holes. But there's no easy builtin properties of tables that can assert it forms a unique predictable sequence (note that the presence of noninteger keys in the table does not invalidate a sequence: a table is a valid sequence depending only on the subset of its keys that are integers, and keys below 1 are ignored: you can safely add a key 0 or 1 to any table that is a sequence without invalidating the sequence and what #t will return). This behavior of tables in Lua and the very weak definition of "sequences" is very tricky. Le mar. 7 mai 2019 à 17:49, Coda Highland <[hidden email]> a écrit :

On Tue, May 7, 2019 at 1:12 PM Philippe Verdy <[hidden email]> wrote:
Except that #s being the length of a string makes sense, because a string is a sequence of characters. But if numbers are considered to be scalar values (as they usually are) then that means they aren't sequences, and the Lua definition of # being the length of a sequence is meaningless. That said, if you step outside of the concrete implementation of numbers in computers, you could use the settheoretic definition of the natural numbers to come up with another interpretation of #n  which would be n itself. Under the ZermeloFraenkel axioms, the natural numbers are built up of sets. 0 is defined as the empty set, and then every natural number afterward is defined as the set of all natural numbers smaller than it. This means the number of elements in the set representing a natural number IS that natural number, and since natural numbers have a defined ordering, that means that a natural number is a sequence. What of negative numbers and noninteger numbers? Well, if we consider a sequence to be something iterable, and the length of a sequence to be the number of elements inspected when iterating over it, then #r would be floor(r) for positive noninteger numbers, as the default notion of iterating over the numbers involves incrementing by 1 and stopping once you've exceeded that number. (It WOULD be ceil, since Lua includes the upper loop bound, except Lua is also 1indexed, which means that the iteration count ends up being the same.) #r would be 0 for negative numbers (whether integer or not) as a for loop with 1 as its lower bound and with a negative number as its upper bound will iterate 0 times. So #n = (n > 0 and floor(n) or 0) is the only definition of # on a number that I can think of that would be consistent with the other sequencerelated uses of the # operator in Lua. /s/ Adam 
On Tue, May 7, 2019 at 1:55 PM Coda Highland <[hidden email]> wrote:
It occurs to me that #n for integer n >= 2^64 or noninteger n > 2^53 would need to be inf, if we say that # returns the number of iterations a loop over its argument would perform. /s/ Adam 
In reply to this post by Andrew Starks2
On Tue, May 7, 2019 at 6:01 PM Andrew Starks wrote:
Why asking mathematicians? Lua is for programmers! ;) Without mushrooms many programmer would want #n to be size of a number in bits #0 == 0 #7 == 3 #8 == 4 #8.0 == 4 #(2^100) == 101#0.01 == 0 #(math.huge) == math.huge #(5) raises error or returns NaN direction of rounding (such as in #7.5) is not specified and depends on implementation 
In reply to this post by Coda Highland
No, 0 is not a valide sequence number... Sequences in Lua are restricted to ordinals from 1 to N (without holes). Note that the first comment about length of numbers was still accurate: it said it used a default conversion of numbers to string. But all the problem is the formatting of this number. PHP made a choice for such representation of numbers as strings, Java as well, for their builtin converters. C/C++ did not make any choice, as the result is dependant of the context and there's no default format. In Lua there's also a default format, the one you see in consoles when printing numbers: this is this format that allows a length to be meaningful. But string lengths are conceprtually the same as sequence lengths in Lua tables (strings in lua are a compact form to store an indexed table of characters enumerable as a valid sequence). For Lua numbers however you need a converter to generate a sequence (of digits in some base, or signs, or decimal and grouping separators, or exponent prefix). Without it you cannot enumerate numbers with a well defined positional index for use as if they were table keys. Note that even if sequence numbers cannot be 0, the sequence length can be 0 of the sequence of empty or is equal to the last key of the enumerated sequence. Le mar. 7 mai 2019 à 20:56, Coda Highland <[hidden email]> a écrit :

On Tue, May 7, 2019 at 6:50 PM Philippe Verdy <[hidden email]> wrote:
As I said, 0 represents the empty set. It IS a sequence, but it's a sequence containing nothing. A loop over the 0 sequence will iterate 0 times. The default format doesn't allow the length to be meaningful as you describe, because that format is platformspecific and varies based on the underlying C library implementation. Furthermore, while it can be called "meaningful" in the sense that you can assign a meaning to it, that doesn't mean it's a useful meaning. That meaning would imply that n[i] would return the i'th character of the string representation of the number, which is  again  a choice you could make that would be welldefined but why would that ever be something you'd want to do, as opposed to converting the number to a string first? If Lua offered a range() function like Python's that could be used analogously to ipairs(), then #n would match the length of the sequence returned by range(). You could similarly define a chars() iterator function for strings such that #s would match the length of that sequence. This would make a very clean symmetry: tables with ipairs(), strings with chars(), numbers with range(), and all of them have the same behavior with #. That said, #n == abs(n) is also a very defensible argument. Instead of trying to generalize numbers as sequences like I did in my previous post, this instead generalizes # as a notion of size. This doesn't have any useful properties with regards to sequences or iteration, but it's robustly nonarbitrary in its meaning. /s/ Adam 
abs(n) is as much arbitrary as the number of digits, i.e. roughly log10(abs(n) for integers... This still does not work properly for nonintegers, or large integers whose integral precision is lost by the value stored in exponential format with an aribtrary fixed number of digits. Also I agree that length == 0 is valid to represent an empty set, but it's still not a valid Lua sequence number. As well "#t" in Lua is not the total number of items in a table, but only the length of one of its extracted sequences.(which are not unique or could be empty if the table has holes for some sequence numbers. Meaning efefctively that "#t" or ipairs(t) is unreliable in Lua for tables, and works only for some of them that are valid sequences. And even if it's a valid sequence, there may still be more items in the table (whose keys are not integers or are integers <= 0 and thus implicitly excluded from sequences). But your initial comment allowed the value 0 in keys of the input table, which was incorrect Because it only allows 0 on valid output for the "length" of some unpredicatable sequence (including an empty sequence) extracted from the table,. If #t == 0, it does not mean that table t is empty.. In summary: saying a table's length == 0 is NOT equivalent to saying that the same table is empty. That's a good reson why the "#" operator and the ipairs() iterator in Lua are unrelaible, unpredictable, you should not create any generic algorigthm assuming it, or you'll need to check the result of pairs(t) to see if it returns at least one (key,value) pair or nil. Le mer. 8 mai 2019 à 02:16, Coda Highland <[hidden email]> a écrit :

On Tue, May 7, 2019 at 10:00 PM Philippe Verdy <[hidden email]> wrote:
Agreed; log10(abs(n)) is a halfway reasonable but still arbitrary choice that still carries the notion of "size".
I'm not sure what you mean by a "sequence number". Do you mean an index? Well of course it isn't. There are no valid indexes into an empty sequence, because it's empty. Why would you EXPECT 0 to be valid? Why does that even matter for anything?
Yes, we've already clearly established that # is only welldefined for proper sequences, which means that this entire discussion is hypothetical handwavy musing. A table can be an improper sequence, at which point # and ipairs don't necessarily align and # is measuring a very specific thing about tables instead of a generic notion of "size". My hypothetical extension of # to numbers does exactly the same thing: for numbers that unambiguously represent a proper sequence given the appropriate iterator, it returns the value you would expect, while providing a welldefined return value when you're outside of the strict domain.
No it didn't...? My initial comment said that if 0 is treated as the upper bound of an iteration then it would perform 0 iterations  it would never try to use 0 as an index.
In the Lua style, I have been careful to define the domain of what is welldefined and what is illdefined, and I have been careful to say exactly what I mean. I never said #t == 0 means the table is empty. I said it means that the SEQUENCE is empty, and I'm right about that. It means that ipairs(t) will perform 0 iterations. And by symmetry, if we create a range() iterator for numbers, then #0 == 0 means that the sequence represented by the number 0 is empty, and range() will perform 0 iterations. To support this notion I also pointed out that a chars() iterator for strings would also have this property. /s/ Adam 
Le mer. 8 mai 2019 à 16:00, Coda Highland <[hidden email]> a écrit :
a "sequence number" is almost synonymous here from "index", but "index" is ambiguous as it relates to any table/array that may be indexed ("index" is really a synonymous of "key" which has arbitrary type in Lua). I used "sequence number" because it is related to the definition of sequences which are contiguous spans of nonzero positive integers. My first reply was related to the fact that you have accepted the "index" 0 which is not a valid sequence number (as returned by ipairs, or used as character positions in strings, which are a compact form of table whose keys are also restricted to nonzero positive integers that also form a sequence of "characters", which do not really exist in Lua because they are represented also by strings of length 1, but that have an accessible code, which is a positiveorzero integer). Reread yoiur initial message to which I first replied, you'll notice the error you made in it and why I replied. 
On Thu, May 9, 2019 at 6:25 AM Philippe Verdy <[hidden email]> wrote:
My INITIAL message that you replied to said that #n should always be 8. I assume you actually meant the next message, where I dive into a settheoretic definition of numbers. I've reread THAT message several times over and nowhere in it did I make any references to using 0 as an index into a sequence  or indeed to using ANY number as an index into a sequence  so I'm really quite confused about what you're talking about. I was confused about it when you replied to it in the first place and I'm still confused now, because you seem to be trying to counter something I never said. /s/ Adam 
Why 8 ? this is even more confusive now... If Lua numbers are implemented as IEEE 64bit doubleprecision floatting points, you mean a number of bytes, but Lua numbers have no defined width/precision and even the datatype "double" in C is not necessary the IEEE 64bit double (even if it's the most common one in today's computers, there are cases where it may be even 10,12 or 16 bytes if Lua numbers are implemented in C as "long double", but this is not in the IEEE standard, every C/C++ compiler may define it as it wants or to fit the underlying architecture or alignment constraints by adding padding bytes). It's possible to integrate Lua with a host language that can process numbers with high precision (e.g. in Mathematica) and where number sizes could be much larger. For 64bit doubles, they have 18 significant decimal digits, and up to 3 digits for unsigned exponents; add the two possible signs, the exponent prefix and the decimal separator (suppose there's no grouping separator used), the common representation will not generate a string longer that 25 characters, plus up to 6 group separators in European/American locales. The length of that string is then bounded (from 1 to 32 at most, these strings cannot be empty, even for NaNs, infinites or denormals, and a Lua number cannot be nil because it's another type and there's no nil in IEEE 64bit, just one or more NaNs). I see no other meaning for what would be the "length" of a number, because the length supposes a vector representation (as a string or in a sequence: what is them implied with "length" is the existence of an iterator for "elements" of numbers, and the common sense for these elements are characters). Of course you could assume another base than 10 and get longer sequences, but a binary base makes no sense for floatting points (there just exists an alternate representation using hexadecimals, and a special "P" prefix instead of "E" for the base16 exponent; there's less base16 significant digits, so the malximum lenth of 32 will not be reached. But do not confuse "length" (the concept for enumerating parts) with "size" (related to internal storage, something you never handle in Lua, except in networking or file API where you'll need a precise size in bytes or bits, and a bitorder, using an APIspecific serializer) Le jeu. 9 mai 2019 à 14:27, Coda Highland <[hidden email]> a écrit :

On May 9, 2019 1:20:19 PM UTC, Philippe Verdy <[hidden email]> wrote: >Why 8 ? this is even more confusive now... Taking a clue from PHP, it should be 6 because "number" is 6 characters long. Unless, of course, it's an integer, then it should be 7.  Storkman 
In reply to this post by Philippe Verdy
On Thu, May 9, 2019 at 8:20 AM Philippe Verdy <[hidden email]> wrote:
Don't read too much into it. I wasn't being serious when I had made that comment. I mean, I'm not serious about any of this, since it's really fairly meaningless to the overall Lua language, but as a mental exercise it's amusing. But the #n == 8 comment was never meant as anything more than a flippant remark. /s/ Adam 
Op Do. 9 Mei 2019 om 15:45 het Coda Highland <[hidden email]> geskryf:
> But the #n == 8 comment was never meant as anything more than a flippant remark. My original motivation (not divulged in the post) was that invoking a function to get the absolute value of a number is really a very cumbersome way for something that can be done by the C ternary operator.Therefore I looked around for a unary operator not yet defined for type "number" and found that __len is the only candidate. It's a tenline patch to lvm.c: 534a535,544 > case LUA_TNUMINT: { > lua_Integer n=ivalue(rb); > setivalue(ra,n<0?n:n); > return; > } > case LUA_TNUMFLT: { > lua_Number x=fltvalue(rb); > setfltvalue(ra,x<0?x:x); > return; > } 
On Thu, May 9, 2019 at 7:43 PM Dirk Laurie wrote:
Ten lines are not enough. What result would you expect for INT_MIN ? 
On Thu, May 9, 2019 at 7:59 PM Egor Skriptunoff wrote:
BTW, math.abs(1<<63) in both Lua 5.3 and 5.4 returns negative value. That's a bug. 
Free forum by Nabble  Edit this page 