Discussion:
NaN in Lua 5.3 Reference Manual
John Hind
2017-06-23 10:41:35 UTC
Permalink
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.
Dirk Laurie
2017-06-23 14:39:22 UTC
Permalink
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
Egor Skriptunoff
2017-06-23 15:15:26 UTC
Permalink
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'.
John Hind
2017-06-23 17:04:07 UTC
Permalink
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" <***@gmail.com>
To: "John Hind" <***@zen.co.uk>; "Lua mailing list"
<lua-***@lists.lua.org>
Sent: 23/06/2017 16:15:26
Subject: Re: NaN in Lua 5.3 Reference Manual
Post by Egor Skriptunoff
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'.
Coda Highland
2017-06-23 17:28:27 UTC
Permalink
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
Sean Conner
2017-06-23 18:49:26 UTC
Permalink
Post by Coda Highland
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
Coda Highland
2017-06-23 19:09:22 UTC
Permalink
Post by Sean Conner
Post by Coda Highland
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
Martin
2017-06-24 04:17:29 UTC
Permalink
[...] 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
Dirk Laurie
2017-06-23 18:59:42 UTC
Permalink
Post by Martin
[...] 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.
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
John Hind
2017-06-24 10:23:29 UTC
Permalink
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: lua-l-***@lists.lua.org
To: lua-***@lists.lua.org
Sent: 01/01/0001 00:00:00
Subject: lua-l Digest, Vol 83, Issue 47
Send lua-l mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of lua-l digest..."
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
Subject: Re: NaN in Lua 5.3 Reference Manual
Content-Type: text/plain; charset="UTF-8"
Post by 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.
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,
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
Subject: Re: NaN in Lua 5.3 Reference Manual
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
Subject: Re[2]: NaN in Lua 5.3 Reference Manual
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
Subject: Re: Re[2]: NaN in Lua 5.3 Reference Manual
Content-Type: text/plain; charset="UTF-8"
Post by 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.
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
Subject: Re: NaN in Lua 5.3 Reference Manual
Content-Type: text/plain; charset=utf-8; format=flowed
Post by John Hind
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
Subject: Re: NaN in Lua 5.3 Reference Manual
Content-Type: text/plain; charset=utf-8
Post by John Hind
[...] 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.
Lua 5.3.3 Copyright (C) 1994-2016 Lua.org, PUC-Rio
Post by John Hind
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
Subject: Yet another user confused by the *program* exporting symbols
(was Re: Symbol not found error using embedded Lua interpreter in
Rust)
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
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lua-l-lists.lua.org
End of lua-l Digest, Vol 83, Issue 47
*************************************
Enrique Garcia Cota
2017-06-24 11:00:31 UTC
Permalink
Hi,

The (odd) requirement of the IEEE standard that NaN not test equal to
Post by John Hind
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
Duncan Cross
2017-06-24 11:56:45 UTC
Permalink
Post by Enrique Garcia Cota
Or if you want something a bit more resistant against tables with metatable
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
Russell Haley
2017-06-24 20:37:07 UTC
Permalink
<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">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.&nbsp;</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">if type(x) ~= 'nan' then</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">...</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">end</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Russ</div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;10&nbsp;smartphone&nbsp;on&nbsp;the&nbsp;Virgin&nbsp;Mobile&nbsp;network.</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Enrique Garcia Cota</div><div><b>Sent: </b>Saturday, June 24, 2017 4:01 AM</div><div><b>To: </b>John Hind; Lua mailing list</div><div><b>Reply To: </b>Lua mailing list</div><div><b>Subject: </b>Re: NaN in Lua 5.3 Reference Manual</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr"><div>Hi,</div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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<br></blockquote><div><br></div><div>Wouldn't this be enough?</div><div><br></div><div>&nbsp; &nbsp; function isNan(x)</div><div>&nbsp; &nbsp; &nbsp; return x ~= x</div><div>&nbsp; &nbsp; end</div><div><br></div><div>Or if you want something a bit more resistant against tables with metatable magic:</div><div><br></div><div><div>&nbsp; &nbsp; function isNan(x)</div><div>&nbsp; &nbsp; &nbsp; return type(x) == 'number' and x ~= x</div><div>&nbsp; &nbsp; end</div></div></div></div></div>
<br><!--end of _originalContent --></div></body></html>
Sean Conner
2017-06-24 21:41:47 UTC
Permalink
Post by John Hind
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.
Post by John Hind
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.
John Hind
2017-06-25 10:27:04 UTC
Permalink
Enrique Garcia Cota said:
<<
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
Oh, that is so cleaver! I should know better than to suggest something
is impossible on this mailing list!

However depending on NaN being the *only* value that is not equal to
itself arguably fails my stipulation of robustness, and intuitive it
ain't! Is 'minus infinity' equal to itself? Is 'minus infinity' equal to
'plus infinity' even? (remembering we we not relying on IEEE
conformance). I think we enter deep philosophical waters!
Dirk Laurie
2017-06-25 13:56:19 UTC
Permalink
However depending on NaN being the *only* value that is not equal to itself
arguably fails my stipulation of robustness, and intuitive it ain't! Is
'minus infinity' equal to itself? Is 'minus infinity' equal to 'plus
infinity' even? (remembering we we not relying on IEEE conformance). I think
we enter deep philosophical waters!
Not philosophical. IEEE 754 is a specification. It says exactly what the bit
patterns are and what they mean.

function hex(x)
if math.type(x)=='float' then
return ("%016x"):format(string.unpack("L",string.pack("d",x)))
end
end

For example:

inf=1/0
hex(inf) --> 7ff0000000000000
hex(-inf) --> fff0000000000000
NaN=0/0
hex(NaN) --> fff8000000000000

However, whereas inf and -inf have unique bit patterns, and therefore
-inf does not equal +inf, NaN doesn't. NaN literally is equivalent to "any
bit pattern not conforming to the specifications for a valid double".
If the thirteen hex digits after 'fff' or '7ff' are anything except zeros,
it counts as a NaN. (That's why it was possible for Lua 5.2 to have
a "NaN trick": those hex digits were exploited.)

Loading...