Support "special" numeric values such as NaN, +Inf and -Inf

[amadawn]

This would be necessary to cover all possible double64 IEEE 754 floating point numbers.

[mrflip]

-1 Is there a reason to allow these in a configuration file?

NaNs in particular require special handling; comparisons are funny: x = Float::NAN ; case x when Float::NAN then puts 'nan' ; else puts 'surprise' ; end; puts (x == x) is 'surprise' and 'false'. In a config file setting you're better off testing for the string 'nan' or doing something else explicitly out of band than allowing NaNs.

As a point of reference, JSON decided to forbid them: "Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted."

[pygy]

Infinity can make sense in some cases. NaN not so much. It does in the context of math operations whose results may be undefined, but are bound to a numeric type.

In a config file, putting a NaN where a number is expected is literally absurd.

[tnm]

Instinct tells me we should probably avoid special case numbers for simplicity reasons, although I do see some of the rationale. It seems pretty common for config files to use 0 in certain context to mean infinity (or unbounded, or similar concepts), which may or may not be good. But weighing positives/negatives, we should probably avoid special case numbers (at least in my initial thoughts on that).

[mojombo]

A big goal for TOML is to be representable as a hash table in many languages. As such, I don't think support for Inf and NaN are wise, as they are difficult to represent in many languages. They also don't have wide applicability (especially NaN).

[flying-sheep]

please reconsider this:

NaN and +-Infinity is part of the IEEE floating point specification, i.e. it’s at the core of likely every single programming language you ever used.

“difficult to represent in many languages” is therefore wrong. please tell me one commonly used language that can’t represent one of those.

JSON not having those makes me rage HARD because it makes the format unable to represent many biological data sets (and i guess also some in most other scientific field). TOML is a configuration language, so them missing is not that important, but it would still be useful for, say, limits and such.

[BurntSushi]

@flying-sheep I'd say that we should hold off on adding it until there is a compelling and broadly applicable use case.

[flying-sheep]

there is, of course. limits.

[Buffers]
maxsize=2048 #set to Inf to disable buffer limits

NaN can be used like in a data set: missing numeric value. the other ones also have practical properties: Inf is a number bigger than all specific numbers, -Inf is a number smaller than all specific numbers.

generally it simply would be useful to be able to represent those not-quite-numbers which are available in pretty much all programming languages (IDK if there even is a counter example).

[BurntSushi]

generally it simply would be useful to be able to represent those not-quite-numbers which are available in pretty much all programming languages (IDK if there even is a counter example).

Yes. Agreed. I don't think that is the issue at hand. The issue at hand is adding more parsing complexity for little gain.

NaN can be used like in a data set: missing numeric value. the other ones also have practical properties: Inf is a number bigger than all specific numbers, -Inf is a number smaller than all specific numbers.

I think I'd rather take the conservative approach here. This is something that can be added in a backwards compatible way. So if it turns out that people really want it, then we could add it.