lua-users home
lua-l archive

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


Why 8 ? this is even more confusive now...
If Lua numbers are implemented as IEEE 64-bit double-precision 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 64-bit 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 64-bit 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 64-bit, 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 base-16 exponent; there's less base-16 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 bit-order, using an API-specific serializer)


Le jeu. 9 mai 2019 à 14:27, Coda Highland <chighland@gmail.com> a écrit :


On Thu, May 9, 2019 at 6:25 AM Philippe Verdy <verdy_p@wanadoo.fr> wrote:


Le mer. 8 mai 2019 à 16:00, Coda Highland <chighland@gmail.com> a écrit :
On Tue, May 7, 2019 at 10:00 PM Philippe Verdy <verdy_p@wanadoo.fr> wrote:
abs(n) is as much arbitrary as the number of digits, i.e. roughly log10(abs(n) for integers...

Agreed; log10(abs(n)) is a halfway reasonable but still arbitrary choice that still carries the notion of "size".
 
Also I agree that length == 0 is valid to represent an empty set, but it's still not a valid Lua sequence number.

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?

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 non-zero 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 non-zero 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 positive-or-zero integer).

Reread yoiur initial message to which I first replied, you'll notice the error you made in it and why I replied.

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 set-theoretic definition of numbers. I've re-read 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