NaN in Lua 5.3 Reference Manual

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

NaN in Lua 5.3 Reference Manual

John Hind
I notice that Lua 5.3 Reference Manual has been extensively edited over
the last few point releases, but one aspect that is still not very well
described is NaN. There are three references to it, all tangential. Two
state that it is not a valid table key while the third describes its
treatment by comparison operators. The thing itself is never properly
introduced.

First we have to face up to a logical incongruity: Not-a-Number (NaN)
*is* a number (type(0/0) == "number")! We probably just have to blame
the IEEE for that bit of stupidity (these standards committees!) and
face up to it instead of glossing over it.

The first reference to NaN occurs in 'Basic Concepts' (2.1) in the
description of the 'table' type: it is stated that, along with nil, NaN
is not a valid table key. Then in parenthesis "Not a Number is a special
value used to represent undefined or unrepresentable numerical results,
such as 0/0." Leaving aside this further logical incongruity (can one
represent the unrepresentable?), it would be clearer to give this
definition earlier, in the paragraph introducing the 'number' type.

Indeed the introduction of two number subtypes 'integer' and 'float'
opens up an opportunity for conceptual clarification. 'NaN' could be
presented as a third subtype. This would not necessarily imply an
implementation change, just a change in the way the concept is presented
in documentation and conceptualised by Lua users. Actually I think it
does in fact pretty accurately describe the current implementation.

Of course, for the next major release, changing the implementation of
math.type to return a third distinguished string key for NaN should be
considered. But this could be independent of changing the conceptual
representation in the Manual which could be done in a point release.


Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Dirk Laurie-2
2017-06-23 12:41 GMT+02:00 John Hind <[hidden email]>:

> I notice that Lua 5.3 Reference Manual has been extensively edited over the
> last few point releases, but one aspect that is still not very well
> described is NaN. There are three references to it, all tangential. Two
> state that it is not a valid table key while the third describes its
> treatment by comparison operators. The thing itself is never properly
> introduced.

NaN is an IEEE-754 subtlety and no more worthy of elaboration in
the Lua manual than a discussion of why n*(1/n)==1 might for some
values of n be false. The properties mentioned in the manual are
precisely the ways in which it impinges on essential Lua issues.

It does fall within the scope of an auxiliary glossary [1] for careful readers,
and there I wrote the following:

NaN
---

Acronym for "Not A Number". An exceptional value of type [number] (also
written 'NAN' and 'nan'), which arises as the result of an undefinable
arithmetic [operation]. NaN is not a Lua keyword, but appears in
output (in some implementations, even the nonsensical '-nan' may
be printed). If you need the notation NaN, assign such
a value to the name.

NaN is not a legal [key] in a table, but counts as [true](truth).

    NaN = 0/0
    NaN + 1        -- NaN. All arithmetic operations involving NaN have
                   -- result NaN.
    NaN <= NaN     -- false. All comparison operations involving NaN have
                   -- result false except the following.
    NaN ~= NaN     -- true. The only Lua value with this property.

[1] https://rawgit.com/dlaurie/lua-notes/master/glossary.html

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Egor Skriptunoff-2
In reply to this post by John Hind
On Fri, Jun 23, 2017 at 1:41 PM, John Hind wrote:
one aspect that is still not very well described is NaN. There are three references to it, all tangential. Two state that it is not a valid table key while the third describes its treatment by comparison operators. The thing itself is never properly introduced.

 
Lua does not introduce NaN by itself (and therefore should not describe it in details).
IEEE-754 clearly defines the value "NaN", and Lua manual just refers (implicitly) to that definition.
Should Lua manual also define what "floating point number" is?  What "integer number" is?  What "string" is?  What "character" is?  What "more", "less" and "equal" mean?

 
"Not a Number is a special value used to represent undefined or unrepresentable numerical results, such as 0/0."
can one represent the unrepresentable?

The value NaN (Not a Number) is used to represent a value that does not represent a real number.
So yes, one can "represent unrepresentable" in more wide superset.
In a similar way, mathematicians "count uncountable".

 
Indeed the introduction of two number subtypes 'integer' and 'float' opens up an opportunity for conceptual clarification. 'NaN' could be presented as a third subtype.

NaN shares semantics of arithmetic operations with all floating point numbers, so there is no need for splitting 'float' into 'real', 'NaN' and 'infinity'.

Reply | Threaded
Open this post in threaded view
|

Re[2]: NaN in Lua 5.3 Reference Manual

John Hind
In this case, I would reference IEEE 754 when 'float number' type is first introduced in section 2.1. I would then remove the reference to NaN from section 3.4.4. That leaves the issue of NaN not being a valid table key. Why not given it is a unique bit pattern in the IEEE 754 code space? But if it is necessary to specifically exclude it, I would refer to it as "the float number value NaN", or "the IEEE 754 value NaN".

Presumably IEEE 754 positive and negative infinity ARE valid table keys, since they are not specifically excluded? What about positive and negative zero? Would these be distinguished table keys?

The problem I had reading section 2.1 is that it implies 'NaN' is something like 'nil' (which as already been introduced) and never explains that it is actually a specific value of the float subtype of the number type.

------ Original Message ------
From: "Egor Skriptunoff" <[hidden email]>
To: "John Hind" <[hidden email]>; "Lua mailing list" <[hidden email]>
Sent: 23/06/2017 16:15:26
Subject: Re: NaN in Lua 5.3 Reference Manual

On Fri, Jun 23, 2017 at 1:41 PM, John Hind wrote:
one aspect that is still not very well described is NaN. There are three references to it, all tangential. Two state that it is not a valid table key while the third describes its treatment by comparison operators. The thing itself is never properly introduced.

 
Lua does not introduce NaN by itself (and therefore should not describe it in details).
IEEE-754 clearly defines the value "NaN", and Lua manual just refers (implicitly) to that definition.
Should Lua manual also define what "floating point number" is?  What "integer number" is?  What "string" is?  What "character" is?  What "more", "less" and "equal" mean?

 
"Not a Number is a special value used to represent undefined or unrepresentable numerical results, such as 0/0."
can one represent the unrepresentable?

The value NaN (Not a Number) is used to represent a value that does not represent a real number.
So yes, one can "represent unrepresentable" in more wide superset.
In a similar way, mathematicians "count uncountable".

 
Indeed the introduction of two number subtypes 'integer' and 'float' opens up an opportunity for conceptual clarification. 'NaN' could be presented as a third subtype.

NaN shares semantics of arithmetic operations with all floating point numbers, so there is no need for splitting 'float' into 'real', 'NaN' and 'infinity'.

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: NaN in Lua 5.3 Reference Manual

Coda Highland
On Fri, Jun 23, 2017 at 12:04 PM, John Hind <[hidden email]> wrote:

> In this case, I would reference IEEE 754 when 'float number' type is first
> introduced in section 2.1. I would then remove the reference to NaN from
> section 3.4.4. That leaves the issue of NaN not being a valid table key. Why
> not given it is a unique bit pattern in the IEEE 754 code space? But if it
> is necessary to specifically exclude it, I would refer to it as "the float
> number value NaN", or "the IEEE 754 value NaN".
>
> Presumably IEEE 754 positive and negative infinity ARE valid table keys,
> since they are not specifically excluded? What about positive and negative
> zero? Would these be distinguished table keys?
>
> The problem I had reading section 2.1 is that it implies 'NaN' is something
> like 'nil' (which as already been introduced) and never explains that it is
> actually a specific value of the float subtype of the number type.

It actually DOESN'T have a unique bit pattern in IEEE-754. All
IEEE-754 numbers with an exponent of all 1's is a NaN, and in fact
some VMs (including LuaJIT) exploit this fact to pack 52 bits of
useful information into the mantissa instead of storing it externally.

The reason section 2.1 doesn't mention IEEE-754 is because the Lua
reference interpreter doesn't rely strictly on IEEE-754 semantics
(notwithstanding the expected behavior of NaN) and it will compile and
run just fine on platforms that use other floating-point
representations (this is mentioned in 3.4.1).

I'm pretty sure you're right that positive and negative infinities are
distinct table keys. I don't think positive and negative zeroes are
because they compare equal to each other in all contexts.

As for referring to it as "the float number value NaN" in section 2.1
-- it already does. The parenthetical note right there calls out that
it is a special value used as a numerical result.

As for removing it from 3.4.4... Why? This definition is actually
required BECAUSE Lua doesn't require that the underlying platform
supports IEEE-754 semantics, but the language guarantees these
semantics anyway. (Also, there are other languages that use IEEE-754
floating point math that give NaN a well-defined comparison value in
order to provide a well-ordering property over the set of all possible
values.)

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

nobody
In reply to this post by John Hind
On 2017-06-23 19:04, John Hind wrote:
> Why not given it is a unique bit pattern in the IEEE 754 code space?

It's not, it's **tons** of different patterns.

Which is precisely why it's a problem:  As float, NaN ~= NaN by
definition.  While reinterpreting the bits as int _usually_ (for NaNs
generated by the FPU) gives the same integers, it's not guaranteed to.
Which means no matter how you compare, it may be that NaN ~= NaN, which
makes recalling things from a hash table kinda awkward.

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Martin
In reply to this post by John Hind
On 06/23/2017 10:04 AM, John Hind wrote:
> [...] What about positive and
> negative zero? Would these be distinguished table keys?

With positive and negative float zeros is funny thing: you can't (I
don't know how) distinguish negative float zero (-0.0) from positive
float zero (0.0). Usually we detect negative number by comparing it with
0, which is not applicable here.

But in tables both three zeros as key maps to integer zero:

  Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
  > t = {[0] = '0', [0.0] = '0.0', [-0.0] = '-0.0'}
  > for k, v in pairs(t) do print(math.type(k), k, v) end
  integer 0 -0.0

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: NaN in Lua 5.3 Reference Manual

Sean Conner
In reply to this post by Coda Highland
It was thus said that the Great Coda Highland once stated:
>
> It actually DOESN'T have a unique bit pattern in IEEE-754. All
> IEEE-754 numbers with an exponent of all 1's is a NaN, and in fact
> some VMs (including LuaJIT) exploit this fact to pack 52 bits of
> useful information into the mantissa instead of storing it externally.

  The exponent of all ones represents two concepts----if the mantissa (the
non-exponent portion) is all zeros, the number is +infinity (or -inifinity
if the sign bit is set).  If the mantissa has any bit set (not all zeros) it
is then considered NaN.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Dirk Laurie-2
In reply to this post by Martin
2017-06-24 6:17 GMT+02:00 Martin <[hidden email]>:

> On 06/23/2017 10:04 AM, John Hind wrote:
>> [...] What about positive and
>> negative zero? Would these be distinguished table keys?
>
> With positive and negative float zeros is funny thing: you can't (I
> don't know how) distinguish negative float zero (-0.0) from positive
> float zero (0.0). Usually we detect negative number by comparing it with
> 0, which is not applicable here.
>
> But in tables both three zeros as key maps to integer zero:
>
>   Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
>   > t = {[0] = '0', [0.0] = '0.0', [-0.0] = '-0.0'}
>   > for k, v in pairs(t) do print(math.type(k), k, v) end
>   integer       0       -0.0

"The expressions a[i] and a[j] denote the same table element if and
only if i and j are raw equal (that is, equal without metamethods).
In particular, floats with integral values are equal to their respective i
ntegers (e.g., 1.0 == 1). To avoid ambiguities, any float with integral
value used as a key is converted to its respective integer."
--- Lua 5.3.4 Reference Manual §2.1

Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: NaN in Lua 5.3 Reference Manual

Coda Highland
In reply to this post by Sean Conner
On Fri, Jun 23, 2017 at 1:49 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Coda Highland once stated:
>>
>> It actually DOESN'T have a unique bit pattern in IEEE-754. All
>> IEEE-754 numbers with an exponent of all 1's is a NaN, and in fact
>> some VMs (including LuaJIT) exploit this fact to pack 52 bits of
>> useful information into the mantissa instead of storing it externally.
>
>   The exponent of all ones represents two concepts----if the mantissa (the
> non-exponent portion) is all zeros, the number is +infinity (or -inifinity
> if the sign bit is set).  If the mantissa has any bit set (not all zeros) it
> is then considered NaN.
>
>   -spc
>
>

Oops. Thanks for the correction.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

John Hind
In reply to this post by John Hind
Thanks everyone, that has been very educational particularly Dirk's
Glossary.

However:

I still maintain it is confusing to have NaN first introduced in the
context of being a disallowed table key. If it is necessary to refer to
it later in the manual it would be better to introduce it with number
type. It is NOT obvious that it is a value of the number-float subtype -
indeed I initially assumed it must be another one value type like Nil.

The (odd) requirement of the IEEE standard that NaN not test equal to
itself means that there is no (robust) way to test for NaN from Lua,
which is surely a significant omission? In the implementation I have to
hand, tostring(0/0) == "-1.#IND", so I could test it that way, but could
I be confident such code would be portable or even if NaN always
converts this way on the same implementation and nothing else does?

If Egor's comment about Lua not requiring the IEEE standard but working
with any underlying float implementation is right, then Dirk's Glossary
is misleading in that the behaviour of zero and infinity would not
necessarily be as defined, even if Lua forces conformity with respect to
NaN (although a non-IEEE float implementation might not support NaN at
all).

Should 0 // 0 result in NaN? (It results in an Error "attempt to divide
by zero" in the implementation I have to hand). Here is where it is
important to know that NaN is a value of number-float subtype rather
than number type. Might it be better (or at least more consistent) if
Lua trapped NaN after resolving an expression and raised the same error?

------ Original Message ------
From: [hidden email]
To: [hidden email]
Sent: 01/01/0001 00:00:00
Subject: lua-l Digest, Vol 83, Issue 47

>Send lua-l mailing list submissions to
> [hidden email]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org
>
>or, via email, send a message with subject or body 'help' to
> [hidden email]
>
>You can reach the person managing the list at
> [hidden email]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of lua-l digest..."
>
>
>Today's Topics:
>
>   1. Re: NaN in Lua 5.3 Reference Manual (Dirk Laurie)
>   2. Re: NaN in Lua 5.3 Reference Manual (Egor Skriptunoff)
>   3. Re[2]: NaN in Lua 5.3 Reference Manual (John Hind)
>   4. Re: Re[2]: NaN in Lua 5.3 Reference Manual (Coda Highland)
>   5. Re: NaN in Lua 5.3 Reference Manual (nobody)
>   6. Re: NaN in Lua 5.3 Reference Manual (Martin)
>   7. Yet another user confused by the *program* exporting symbols
>      (was Re: Symbol not found error using embedded Lua interpreter in
>      Rust) (Jay Carlson)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 23 Jun 2017 16:39:22 +0200
>From: Dirk Laurie <[hidden email]>
>Subject: Re: NaN in Lua 5.3 Reference Manual
>To: Lua mailing list <[hidden email]>
>Message-ID:
> <CABcj=tkuPBhm3JcDwdJnqOgWRHhjJEt2=[hidden email]>
>Content-Type: text/plain; charset="UTF-8"
>
>2017-06-23 12:41 GMT+02:00 John Hind <[hidden email]>:
>
>>I notice that Lua 5.3 Reference Manual has been extensively edited
>>over the
>>last few point releases, but one aspect that is still not very well
>>described is NaN. There are three references to it, all tangential.
>>Two
>>state that it is not a valid table key while the third describes its
>>treatment by comparison operators. The thing itself is never properly
>>introduced.
>
>NaN is an IEEE-754 subtlety and no more worthy of elaboration in
>the Lua manual than a discussion of why n*(1/n)==1 might for some
>values of n be false. The properties mentioned in the manual are
>precisely the ways in which it impinges on essential Lua issues.
>
>It does fall within the scope of an auxiliary glossary [1] for careful
>readers,
>and there I wrote the following:
>
>NaN
>---
>
>Acronym for "Not A Number". An exceptional value of type [number] (also
>written 'NAN' and 'nan'), which arises as the result of an undefinable
>arithmetic [operation]. NaN is not a Lua keyword, but appears in
>output (in some implementations, even the nonsensical '-nan' may
>be printed). If you need the notation NaN, assign such
>a value to the name.
>
>NaN is not a legal [key] in a table, but counts as [true](truth).
>
>    NaN = 0/0
>    NaN + 1        -- NaN. All arithmetic operations involving NaN have
>                   -- result NaN.
>    NaN <= NaN     -- false. All comparison operations involving NaN
>have
>                   -- result false except the following.
>    NaN ~= NaN     -- true. The only Lua value with this property.
>
>[1] https://rawgit.com/dlaurie/lua-notes/master/glossary.html
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 23 Jun 2017 18:15:26 +0300
>From: Egor Skriptunoff <[hidden email]>
>Subject: Re: NaN in Lua 5.3 Reference Manual
>To: John Hind <[hidden email]>, Lua mailing list
> <[hidden email]>
>Message-ID:
> <CAPweGw6V=[hidden email]>
>Content-Type: text/plain; charset="utf-8"
>
>T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTo0MSBQTSwgSm9obiBIaW5kIHdyb3RlOgoKPiBvbmUg
>YXNwZWN0IHRoYXQgaXMgc3RpbGwgbm90IHZlcnkgd2VsbCBkZXNjcmliZWQgaXMgTmFOLiBUaGVy
>ZSBhcmUgdGhyZWUKPiByZWZlcmVuY2VzIHRvIGl0LCBhbGwgdGFuZ2VudGlhbC4gVHdvIHN0YXRl
>IHRoYXQgaXQgaXMgbm90IGEgdmFsaWQgdGFibGUKPiBrZXkgd2hpbGUgdGhlIHRoaXJkIGRlc2Ny
>aWJlcyBpdHMgdHJlYXRtZW50IGJ5IGNvbXBhcmlzb24gb3BlcmF0b3JzLiBUaGUKPiB0aGluZyBp
>dHNlbGYgaXMgbmV2ZXIgcHJvcGVybHkgaW50cm9kdWNlZC4KPgo+Ckx1YSBkb2VzIG5vdCBpbnRy
>b2R1Y2UgTmFOIGJ5IGl0c2VsZiAoYW5kIHRoZXJlZm9yZSBzaG91bGQgbm90IGRlc2NyaWJlIGl0
>CmluIGRldGFpbHMpLgpJRUVFLTc1NCBjbGVhcmx5IGRlZmluZXMgdGhlIHZhbHVlICJOYU4iLCBh
>bmQgTHVhIG1hbnVhbCBqdXN0IHJlZmVycwooaW1wbGljaXRseSkgdG8gdGhhdCBkZWZpbml0aW9u
>LgpTaG91bGQgTHVhIG1hbnVhbCBhbHNvIGRlZmluZSB3aGF0ICJmbG9hdGluZyBwb2ludCBudW1i
>ZXIiIGlzPyAgV2hhdAoiaW50ZWdlciBudW1iZXIiIGlzPyAgV2hhdCAic3RyaW5nIiBpcz8gIFdo
>YXQgImNoYXJhY3RlciIgaXM/ICBXaGF0ICJtb3JlIiwKImxlc3MiIGFuZCAiZXF1YWwiIG1lYW4/
>CgoKCj4gIk5vdCBhIE51bWJlciBpcyBhIHNwZWNpYWwgdmFsdWUgdXNlZCB0byByZXByZXNlbnQg
>dW5kZWZpbmVkIG9yCj4gdW5yZXByZXNlbnRhYmxlIG51bWVyaWNhbCByZXN1bHRzLCBzdWNoIGFz
>IDAvMC4iCj4KY2FuIG9uZSByZXByZXNlbnQgdGhlIHVucmVwcmVzZW50YWJsZT8KPgoKVGhlIHZh
>bHVlIE5hTiAoTm90IGEgTnVtYmVyKSBpcyB1c2VkIHRvIHJlcHJlc2VudCBhIHZhbHVlIHRoYXQg
>ZG9lcyBub3QKcmVwcmVzZW50IGEgcmVhbCBudW1iZXIuClNvIHllcywgb25lIGNhbiAicmVwcmVz
>ZW50IHVucmVwcmVzZW50YWJsZSIgaW4gbW9yZSB3aWRlIHN1cGVyc2V0LgpJbiBhIHNpbWlsYXIg
>d2F5LCBtYXRoZW1hdGljaWFucyAiY291bnQgdW5jb3VudGFibGUiLgoKCgo+IEluZGVlZCB0aGUg
>aW50cm9kdWN0aW9uIG9mIHR3byBudW1iZXIgc3VidHlwZXMgJ2ludGVnZXInIGFuZCAnZmxvYXQn
>IG9wZW5zCj4gdXAgYW4gb3Bwb3J0dW5pdHkgZm9yIGNvbmNlcHR1YWwgY2xhcmlmaWNhdGlvbi4g
>J05hTicgY291bGQgYmUgcHJlc2VudGVkIGFzCj4gYSB0aGlyZCBzdWJ0eXBlLgo+CgpOYU4gc2hh
>cmVzIHNlbWFudGljcyBvZiBhcml0aG1ldGljIG9wZXJhdGlvbnMgd2l0aCBhbGwgZmxvYXRpbmcg
>cG9pbnQKbnVtYmVycywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3Igc3BsaXR0aW5nICdmbG9hdCcg
>aW50byAncmVhbCcsICdOYU4nIGFuZAonaW5maW5pdHknLgotLS0tLS0tLS0tLS0tLSBuZXh0IHBh
>cnQgLS0tLS0tLS0tLS0tLS0KQW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLgpVUkw6
>IGh0dHA6Ly9saXN0bWFzdGVyLnBlcHBlcmZpc2gubmV0L2NnaS1iaW4vbWFpbG1hbi9wcml2YXRl
>L2x1YS1sLWxpc3RzLmx1YS5vcmcvYXR0YWNobWVudHMvMjAxNzA2MjMvYjNmZTAwZDAvYXR0YWNo
>bWVudC0wMDAxLmh0bWwK
>
>------------------------------
>
>Message: 3
>Date: Fri, 23 Jun 2017 17:04:07 +0000
>From: "John Hind" <[hidden email]>
>Subject: Re[2]: NaN in Lua 5.3 Reference Manual
>To: "Egor Skriptunoff" <[hidden email]>, "Lua mailing
> list" <[hidden email]>
>Message-ID: <em89f516ee-d98d-4b1a-988b-bade02519329@cruncher>
>Content-Type: text/plain; charset="utf-8"
>
>SW4gdGhpcyBjYXNlLCBJIHdvdWxkIHJlZmVyZW5jZSBJRUVFIDc1NCB3aGVuICdmbG9hdCBudW1i
>ZXInIHR5cGUgaXMgCmZpcnN0IGludHJvZHVjZWQgaW4gc2VjdGlvbiAyLjEuIEkgd291bGQgdGhl
>biByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byAKTmFOIGZyb20gc2VjdGlvbiAzLjQuNC4gVGhhdCBs
>ZWF2ZXMgdGhlIGlzc3VlIG9mIE5hTiBub3QgYmVpbmcgYSB2YWxpZCAKdGFibGUga2V5LiBXaHkg
>bm90IGdpdmVuIGl0IGlzIGEgdW5pcXVlIGJpdCBwYXR0ZXJuIGluIHRoZSBJRUVFIDc1NCBjb2Rl
>IApzcGFjZT8gQnV0IGlmIGl0IGlzIG5lY2Vzc2FyeSB0byBzcGVjaWZpY2FsbHkgZXhjbHVkZSBp
>dCwgSSB3b3VsZCByZWZlciAKdG8gaXQgYXMgInRoZSBmbG9hdCBudW1iZXIgdmFsdWUgTmFOIiwg
>b3IgInRoZSBJRUVFIDc1NCB2YWx1ZSBOYU4iLgoKUHJlc3VtYWJseSBJRUVFIDc1NCBwb3NpdGl2
>ZSBhbmQgbmVnYXRpdmUgaW5maW5pdHkgQVJFIHZhbGlkIHRhYmxlIGtleXMsIApzaW5jZSB0aGV5
>IGFyZSBub3Qgc3BlY2lmaWNhbGx5IGV4Y2x1ZGVkPyBXaGF0IGFib3V0IHBvc2l0aXZlIGFuZCAK
>bmVnYXRpdmUgemVybz8gV291bGQgdGhlc2UgYmUgZGlzdGluZ3Vpc2hlZCB0YWJsZSBrZXlzPwoK
>VGhlIHByb2JsZW0gSSBoYWQgcmVhZGluZyBzZWN0aW9uIDIuMSBpcyB0aGF0IGl0IGltcGxpZXMg
>J05hTicgaXMgCnNvbWV0aGluZyBsaWtlICduaWwnICh3aGljaCBhcyBhbHJlYWR5IGJlZW4gaW50
>cm9kdWNlZCkgYW5kIG5ldmVyIApleHBsYWlucyB0aGF0IGl0IGlzIGFjdHVhbGx5IGEgc3BlY2lm
>aWMgdmFsdWUgb2YgdGhlIGZsb2F0IHN1YnR5cGUgb2YgCnRoZSBudW1iZXIgdHlwZS4KCi0tLS0t
>LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLQpGcm9tOiAiRWdvciBTa3JpcHR1bm9mZiIgPGVnb3Iu
>c2tyaXB0dW5vZmZAZ21haWwuY29tPgpUbzogIkpvaG4gSGluZCIgPGpvaG4uaGluZEB6ZW4uY28u
>dWs+OyAiTHVhIG1haWxpbmcgbGlzdCIgCjxsdWEtbEBsaXN0cy5sdWEub3JnPgpTZW50OiAyMy8w
>Ni8yMDE3IDE2OjE1OjI2ClN1YmplY3Q6IFJlOiBOYU4gaW4gTHVhIDUuMyBSZWZlcmVuY2UgTWFu
>dWFsCgo+T24gRnJpLCBKdW4gMjMsIDIwMTcgYXQgMTo0MSBQTSwgSm9obiBIaW5kIHdyb3RlOgo+
>Pm9uZSBhc3BlY3QgdGhhdCBpcyBzdGlsbCBub3QgdmVyeSB3ZWxsIGRlc2NyaWJlZCBpcyBOYU4u
>IFRoZXJlIGFyZSAKPj50aHJlZSByZWZlcmVuY2VzIHRvIGl0LCBhbGwgdGFuZ2VudGlhbC4gVHdv
>IHN0YXRlIHRoYXQgaXQgaXMgbm90IGEgCj4+dmFsaWQgdGFibGUga2V5IHdoaWxlIHRoZSB0aGly
>ZCBkZXNjcmliZXMgaXRzIHRyZWF0bWVudCBieSBjb21wYXJpc29uIAo+Pm9wZXJhdG9ycy4gVGhl
>IHRoaW5nIGl0c2VsZiBpcyBuZXZlciBwcm9wZXJseSBpbnRyb2R1Y2VkLgo+Pgo+Cj5MdWEgZG9l
>cyBub3QgaW50cm9kdWNlIE5hTiBieSBpdHNlbGYgKGFuZCB0aGVyZWZvcmUgc2hvdWxkIG5vdCBk
>ZXNjcmliZSAKPml0IGluIGRldGFpbHMpLgo+SUVFRS03NTQgY2xlYXJseSBkZWZpbmVzIHRoZSB2
>YWx1ZSAiTmFOIiwgYW5kIEx1YSBtYW51YWwganVzdCByZWZlcnMgCj4oaW1wbGljaXRseSkgdG8g
>dGhhdCBkZWZpbml0aW9uLgo+U2hvdWxkIEx1YSBtYW51YWwgYWxzbyBkZWZpbmUgd2hhdCAiZmxv
>YXRpbmcgcG9pbnQgbnVtYmVyIiBpcz8gIFdoYXQgCj4iaW50ZWdlciBudW1iZXIiIGlzPyAgV2hh
>dCAic3RyaW5nIiBpcz8gIFdoYXQgImNoYXJhY3RlciIgaXM/ICBXaGF0IAo+Im1vcmUiLCAibGVz
>cyIgYW5kICJlcXVhbCIgbWVhbj8KPgo+Cj4+Ik5vdCBhIE51bWJlciBpcyBhIHNwZWNpYWwgdmFs
>dWUgdXNlZCB0byByZXByZXNlbnQgdW5kZWZpbmVkIG9yIAo+PnVucmVwcmVzZW50YWJsZSBudW1l
>cmljYWwgcmVzdWx0cywgc3VjaCBhcyAwLzAuIgo+PmNhbiBvbmUgcmVwcmVzZW50IHRoZSB1bnJl
>cHJlc2VudGFibGU/Cj4KPlRoZSB2YWx1ZSBOYU4gKE5vdCBhIE51bWJlcikgaXMgdXNlZCB0byBy
>ZXByZXNlbnQgYSB2YWx1ZSB0aGF0IGRvZXMgbm90IAo+cmVwcmVzZW50IGEgcmVhbCBudW1iZXIu
>Cj5TbyB5ZXMsIG9uZSBjYW4gInJlcHJlc2VudCB1bnJlcHJlc2VudGFibGUiIGluIG1vcmUgd2lk
>ZSBzdXBlcnNldC4KPkluIGEgc2ltaWxhciB3YXksIG1hdGhlbWF0aWNpYW5zICJjb3VudCB1bmNv
>dW50YWJsZSIuCj4KPgo+PkluZGVlZCB0aGUgaW50cm9kdWN0aW9uIG9mIHR3byBudW1iZXIgc3Vi
>dHlwZXMgJ2ludGVnZXInIGFuZCAnZmxvYXQnIAo+Pm9wZW5zIHVwIGFuIG9wcG9ydHVuaXR5IGZv
>ciBjb25jZXB0dWFsIGNsYXJpZmljYXRpb24uICdOYU4nIGNvdWxkIGJlIAo+PnByZXNlbnRlZCBh
>cyBhIHRoaXJkIHN1YnR5cGUuCj4KPk5hTiBzaGFyZXMgc2VtYW50aWNzIG9mIGFyaXRobWV0aWMg
>b3BlcmF0aW9ucyB3aXRoIGFsbCBmbG9hdGluZyBwb2ludCAKPm51bWJlcnMsIHNvIHRoZXJlIGlz
>IG5vIG5lZWQgZm9yIHNwbGl0dGluZyAnZmxvYXQnIGludG8gJ3JlYWwnLCAnTmFOJyAKPmFuZCAn
>aW5maW5pdHknLgo+Ci0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQpBbiBI
>VE1MIGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uClVSTDogaHR0cDovL2xpc3RtYXN0ZXIucGVw
>cGVyZmlzaC5uZXQvY2dpLWJpbi9tYWlsbWFuL3ByaXZhdGUvbHVhLWwtbGlzdHMubHVhLm9yZy9h
>dHRhY2htZW50cy8yMDE3MDYyMy8wMjllZmE0Yi9hdHRhY2htZW50LTAwMDEuaHRtbAo=
>
>------------------------------
>
>Message: 4
>Date: Fri, 23 Jun 2017 12:28:27 -0500
>From: Coda Highland <[hidden email]>
>Subject: Re: Re[2]: NaN in Lua 5.3 Reference Manual
>To: John Hind <[hidden email]>, Lua mailing list
> <[hidden email]>
>Message-ID:
> <[hidden email]>
>Content-Type: text/plain; charset="UTF-8"
>
>On Fri, Jun 23, 2017 at 12:04 PM, John Hind <[hidden email]>
>wrote:
>>In this case, I would reference IEEE 754 when 'float number' type is
>>first
>>introduced in section 2.1. I would then remove the reference to NaN
>>from
>>section 3.4.4. That leaves the issue of NaN not being a valid table
>>key. Why
>>not given it is a unique bit pattern in the IEEE 754 code space? But
>>if it
>>is necessary to specifically exclude it, I would refer to it as "the
>>float
>>number value NaN", or "the IEEE 754 value NaN".
>>
>>Presumably IEEE 754 positive and negative infinity ARE valid table
>>keys,
>>since they are not specifically excluded? What about positive and
>>negative
>>zero? Would these be distinguished table keys?
>>
>>The problem I had reading section 2.1 is that it implies 'NaN' is
>>something
>>like 'nil' (which as already been introduced) and never explains that
>>it is
>>actually a specific value of the float subtype of the number type.
>
>It actually DOESN'T have a unique bit pattern in IEEE-754. All
>IEEE-754 numbers with an exponent of all 1's is a NaN, and in fact
>some VMs (including LuaJIT) exploit this fact to pack 52 bits of
>useful information into the mantissa instead of storing it externally.
>
>The reason section 2.1 doesn't mention IEEE-754 is because the Lua
>reference interpreter doesn't rely strictly on IEEE-754 semantics
>(notwithstanding the expected behavior of NaN) and it will compile and
>run just fine on platforms that use other floating-point
>representations (this is mentioned in 3.4.1).
>
>I'm pretty sure you're right that positive and negative infinities are
>distinct table keys. I don't think positive and negative zeroes are
>because they compare equal to each other in all contexts.
>
>As for referring to it as "the float number value NaN" in section 2.1
>-- it already does. The parenthetical note right there calls out that
>it is a special value used as a numerical result.
>
>As for removing it from 3.4.4... Why? This definition is actually
>required BECAUSE Lua doesn't require that the underlying platform
>supports IEEE-754 semantics, but the language guarantees these
>semantics anyway. (Also, there are other languages that use IEEE-754
>floating point math that give NaN a well-defined comparison value in
>order to provide a well-ordering property over the set of all possible
>values.)
>
>/s/ Adam
>
>
>
>------------------------------
>
>Message: 5
>Date: Fri, 23 Jun 2017 19:31:32 +0200
>From: nobody <[hidden email]>
>Subject: Re: NaN in Lua 5.3 Reference Manual
>To: [hidden email]
>Message-ID: <[hidden email]>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>On 2017-06-23 19:04, John Hind wrote:
>>Why not given it is a unique bit pattern in the IEEE 754 code space?
>
>It's not, it's **tons** of different patterns.
>
>Which is precisely why it's a problem:  As float, NaN ~= NaN by
>definition.  While reinterpreting the bits as int _usually_ (for NaNs
>generated by the FPU) gives the same integers, it's not guaranteed to.
>Which means no matter how you compare, it may be that NaN ~= NaN, which
>makes recalling things from a hash table kinda awkward.
>
>-- nobody
>
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 23 Jun 2017 21:17:29 -0700
>From: Martin <[hidden email]>
>Subject: Re: NaN in Lua 5.3 Reference Manual
>To: John Hind <[hidden email]>, Lua mailing list
> <[hidden email]>
>Message-ID: <[hidden email]>
>Content-Type: text/plain; charset=utf-8
>
>On 06/23/2017 10:04 AM, John Hind wrote:
>>[...] What about positive and
>>negative zero? Would these be distinguished table keys?
>
>With positive and negative float zeros is funny thing: you can't (I
>don't know how) distinguish negative float zero (-0.0) from positive
>float zero (0.0). Usually we detect negative number by comparing it
>with
>0, which is not applicable here.
>
>But in tables both three zeros as key maps to integer zero:
>
>  Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
>  > t = {[0] = '0', [0.0] = '0.0', [-0.0] = '-0.0'}
>  > for k, v in pairs(t) do print(math.type(k), k, v) end
>  integer 0 -0.0
>
>-- Martin
>
>
>
>------------------------------
>
>Message: 7
>Date: Fri, 23 Jun 2017 18:46:23 +0000
>From: Jay Carlson <[hidden email]>
>Subject: Yet another user confused by the *program* exporting symbols
> (was Re: Symbol not found error using embedded Lua interpreter in
> Rust)
>To: Lua mailing list <[hidden email]>
>Message-ID:
> <CAJgdgDcq=[hidden email]>
>Content-Type: text/plain; charset="utf-8"
>
>Tm90ZSB0aGF0IHRoZSBiZWxvdyBpcyBub3QgcmVsZXZhbnQgdG8gYW55IHN5c3RlbXMgbW9yZSBl
>bWJlZGRlZCB0aGFuIGEKcm91dGVyOyB0aGV5IHdvbid0IGNhcmUgYmVjYXVzZSB0aGV5IHdvbid0
>IHVzZSBFTEYgU1ZSNC1zdHlsZSBzaGFyZWQKbGlicmFyaWVzLgoKSU1PLCB0aGUgbW9zdCBjb21w
>ZWxsaW5nIGFyZ3VtZW50IGZvciB0aGUgb2RkIHdheSB1cHN0cmVhbSBwcmVmZXJzIHRvIGJ1aWxk
>Cm1vZHVsZXMgaXMgdGhhdCB0aGUgbWFpbiBwcm9ncmFtIGRvZXMgbm90IGhhdmUgdG8gYmUgcG9z
>aXRpb24taW5kZXBlbmRlbnQuCk9uIHNvbWUgYXJjaGl0ZWN0dXJlcywgdGhlcmUgaXMgYSBsYXJn
>ZSBwZW5hbHR5IGZvciBQSUMsIGVzcGVjaWFsbHkgb24gaTM4NgppbXBsZW1lbnRhdGlvbnMuIChG
>b3Igc3RhcnRlcnMsIHlvdSBsb3NlIGEgdmVyeSBzY2FyY2UgcmVnaXN0ZXIuKSBVc2luZwovdXNy
>L2Jpbi9sdWEgYXMgbGlibHVhLnNvIGFzIHdlbGwgaGVscGVkIGdldCBMdWEgdG8gdGhlIHRvcCBv
>ZiB0aGUKcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugc2hvb3RvdXQuCgpXZSdyZSBqdXN0IGFib3V0IGF0
>IHRoZSBlbmQgb2YgdGhlIGkzODYgYXJjaGl0ZWN0dXJlLiBBbGwgdGhlIG90aGVyCnBsYXRmb3Jt
>cyB3aGljaCBjb3VsZCB1c2Ugc2hhcmVkIGxpYnJhcmllcyBhcmUgbm90IHNvIHJlZ2lzdGVyLXN0
>YXJ2ZWQuIEluCnRoZSAiUEMiIHNwYWNlLCBhbG1vc3QgZXZlcnl0aGluZyBpcyBhbWQ2NCwgYW5k
>IGFtZDY0IGlzIG11Y2ggYmV0dGVyIGZvcgpwb3NpdGlvbi1pbmRlcGVuZGVudCBjb2RlLgoKSW4g
>YWRkaXRpb24sIHRoZSBwcmVmZXJyZWQgd2F5IHRvIGJ1aWxkIGxpYmx1YS5zbyB0aGVzZSBkYXlz
>IGlzIHRvIG9ubHkKZXhwb3J0IHRoZSBwdWJsaWMgTHVhIEFQSS4gVGhpcyBhbGxvd3MgdGhlIGxp
>bmtlciB0byBvcHRpbWl6ZSBpbnRlcm5hbApyZWZlcmVuY2VzIHRvIHByaXZhdGUgc3ltYm9scy4K
>Ckkgd291bGQgcnVuIGJlbmNobWFya3MgZm9yIHlvdSBpbiBteSBtdXNldW0sIGJ1dCBJIHdvdWxk
>IG5lZWQgc29tZQpiZW5jaG1hcmtzIHRvIHJ1bi4gQW55IHBvaW50ZXJzIG9yIHZvbHVudGVlcnM/
>CgpKYXkKCihPdmVyaGVhZCBjb3VsZCBiZSByZWR1Y2VkIG1vcmUgaWYgZXh0ZXJuYWwgc3ltYm9s
>cyBkaWQgbm90IGFmZmVjdCBob3cKbGlibHVhLnNvIHJlZmVycyB0byB0aGUgbGlibHVhLnNvIHN5
>bWJvbHMuIFRoaXMgYnJlYWtzIExEX1BSRUxPQUQgYW1vbmcKb3RoZXIgdGhpbmdzLCBidXQgaXQn
>cyBhYm91dCBtb3JhbGx5IGVxdWl2YWxlbnQgdG8gZXhwb3J0aW5nIHN5bWJvbHMgZnJvbQp0aGUg
>bWFpbiBwcm9ncmFtLikKCk9uIFRodSwgSnVuIDIyLCAyMDE3LCAwMDozMiBEZWVwYWsgSm9pcyA8
>ZGVlcGFrLmpvaXNAZ21haWwuY29tPiB3cm90ZToKCj4gVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlv
>bnMuCj4KPiBPbiBXZWQsIEp1biAyMSwgMjAxNyBhdCAxOjI2IFBNLCBEZWVwYWsgSm9pcyA8ZGVl
>cGFrLmpvaXNAZ21haWwuY29tPgo+IHdyb3RlOgo+ID4gSXMgdGhlcmUgYSBzcGVjaWZpYyB3YXkg
>dG8gbGluayB0aGUgTHVhIGNvZGUgaW5zaWRlIG9mIFJ1c3QKPiA+IHNvIHRoYXQgdGhlIHN5bWJv
>bHMgYXJlIGF2YWlsYWJsZSB0byB0aGUgQyBtb2R1bGU/Cj4KPiBGV0lXLCBJIG1hbmFnZWQgdG8g
>c29sdmUgdGhpcyBieSBsaW5raW5nIHRoZSBSdXN0IHByb2dyYW0gd2l0aCB0aGUKPiByaWdodCBm
>bGFncy4gSSBoYWQgdG8gcGFzcyBhIGZsYWcgLXJkeW5hbWljLgo+Cj4gSSBqdXN0IGZvdW5kIHRo
>ZSBhbnN3ZXIgYnkgZG9pbmcgYSBsb3Qgb2YgdHJpYWwgYW5kIGVycm9yLCBhbmQKPiByZXNlYXJj
>aC4gSSBjYW7igJl0IGNsYWltIEkgdW5kZXJzdGFuZCBhbGwgdGhlIG15c3RlcmllcyBvZiBsaW5r
>aW5nLiBJCj4gd29uZGVyIGlmIHRoaXMgc29ydCBvZiBpbmZvIGlzIGFscmVhZHkgdGhlcmUgb24g
>c29tZSBMdWEgd2lraS4gSWYgbm90LAo+IEkgd291bGQgYWRkIGl0IHRvIGFuIGFwcHJvcHJpYXRl
>IHBsYWNlIGlmIHNvbWVib2R5IGNhbiBwb2ludCBpdCBvdXQgdG8KPiBtZS4KPgo+IFNvbWUgaGVs
>cGZ1bCBsaW5rcyBmb3IgYW55Ym9keSB3aG8gbWlnaHQgZW5kIHVwIGluIHRoZSBhcmNoaXZlcwo+
>IHNlYXJjaGluZyBmb3IgdGhlIGV4YWN0IHNhbWUgcHJvYmxlbToKPgo+ICoKPiBodHRwczovL3N0
>YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy8yMTI3OTAzNi93aGF0LWlzLWNsYW5ncy1lcXVpdmFs
>ZW50LXRvLXJkeW5hbWljLWdjYy1mbGFnCj4KPiAqIGh0dHA6Ly9rZWl0YWl0by5jb20vYmxvZy8y
>MDE3LzAxLzAyL2V4cGxvcmluZy1jb21waWxlci1vcHRpb25zLmh0bWwKPgo+Ci0tLS0tLS0tLS0t
>LS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQpBbiBIVE1MIGF0dGFjaG1lbnQgd2FzIHNjcnVi
>YmVkLi4uClVSTDogaHR0cDovL2xpc3RtYXN0ZXIucGVwcGVyZmlzaC5uZXQvY2dpLWJpbi9tYWls
>bWFuL3ByaXZhdGUvbHVhLWwtbGlzdHMubHVhLm9yZy9hdHRhY2htZW50cy8yMDE3MDYyMy83NGMx
>YzEwYy9hdHRhY2htZW50Lmh0bWwK
>
>------------------------------
>
>_______________________________________________
>lua-l mailing list
>[hidden email]
>http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org
>
>
>End of lua-l Digest, Vol 83, Issue 47
>*************************************


Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Enrique Garcia Cota
Hi,

The (odd) requirement of the IEEE standard that NaN not test equal to itself means that there is no (robust) way to test for NaN from Lua

Wouldn't this be enough?

    function isNan(x)
      return x ~= x
    end

Or if you want something a bit more resistant against tables with metatable magic:

    function isNan(x)
      return type(x) == 'number' and x ~= x
    end
Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Duncan Cross
On Sat, Jun 24, 2017 at 12:00 PM, Enrique Garcia Cota <[hidden email]> wrote:
> Or if you want something a bit more resistant against tables with metatable
> magic:

I believe this is not necessary -- the __eq metamethod is invoked only
if the two values are "not primitively equal", according to the
manual, so you cannot make a table unequal to itself in that way.

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Russell Haley
In reply to this post by Enrique Garcia Cota
As someone with little math background it seem logical that the language should have a built in test for this as the implementation details of testing for NaN are outside the scope of most people's understanding, yet it is something that is important to test for. This train of thought would support Mr. Hinds argument that it should be considered a numerical subtype that would return a distinguished value. 

if type(x) ~= 'nan' then
...
end

Russ

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
From: Enrique Garcia Cota
Sent: Saturday, June 24, 2017 4:01 AM
To: John Hind; Lua mailing list
Reply To: Lua mailing list
Subject: Re: NaN in Lua 5.3 Reference Manual

Hi,

The (odd) requirement of the IEEE standard that NaN not test equal to itself means that there is no (robust) way to test for NaN from Lua

Wouldn't this be enough?

    function isNan(x)
      return x ~= x
    end

Or if you want something a bit more resistant against tables with metatable magic:

    function isNan(x)
      return type(x) == 'number' and x ~= x
    end

Reply | Threaded
Open this post in threaded view
|

Re: NaN in Lua 5.3 Reference Manual

Sean Conner
In reply to this post by John Hind
It was thus said that the Great John Hind once stated:
> If Egor's comment about Lua not requiring the IEEE standard but working
> with any underlying float implementation is right, then Dirk's Glossary
> is misleading in that the behaviour of zero and infinity would not
> necessarily be as defined, even if Lua forces conformity with respect to
> NaN (although a non-IEEE float implementation might not support NaN at
> all).

  I have access to a system that has floating point math, but not IEEE 754
(having been implemented before the 1985 standard).  It's a software
implementation for the 6809 written by Microsoft [1].  Any division by 0
results in a runtime error ("?/0 ERROR"), unlike IEEE 754 [2].  A too large
value results again in a runtime error ("?OV ERROR") unlike IEEE 754 [3].

  The likelyhood of anyone coming into contact with a non-IEEE 754 floating
point system is very nearly nil these days (with the exception of legacy
systems where floating point was implemented prior to 1985, like the VAX
[4]).  So while Lua can work with non-IEEE 754 floating point, there very
well might be code out there that won't work on such a system.

> Should 0 // 0 result in NaN? (It results in an Error "attempt to divide
> by zero" in the implementation I have to hand). Here is where it is
> important to know that NaN is a value of number-float subtype rather
> than number type. Might it be better (or at least more consistent) if
> Lua trapped NaN after resolving an expression and raised the same error?

  IEEE 754 has verbiage about trapping NaNs but most systems (in my
experience) has such behavior disabled (allowable by the standard).  If you
are really concerned about it, you can enable such traps [5].

  -spc

[1] The Tandy Color Computer.  Microsoft provided the built in BASIC.

[2] x/0 where x != 0 results in +inf or -inf, depending upon the sign
        of x.  0/0 results in NaN.

[3] Which ends up in either +inf or -inf.

[4] The only system I can think where one might actually be able to
        compile and use Lua today.

[5] Consult your systems manual for instructions on which functions to
        call.  These would be C functions, by the way.