Wikifunctions:Type proposals/float64

Done Z20838

Summary

IEEE 754 double-precision floating-point format is a widely supported floating-point number. Note this type will natively support Inf and NaN. It can also precisely represent integer with no more than 53 bits.

Uses

Structure

There are three potential way to store a float64:

Proposal 1

Store the bytes in a raw format, e.g. a list of exactly 8 Z80, representing the raw IEEE 754 representation of a float.

Proposal 2

Stored as a string of the format (nan|-?inf|(0|[1-9]\d*)\.\d+|-?[1-9]\.\d+e[+-][1-9]\d{0,2})

Proposal 3

Store the components of the float as the following keys:

K1: "sign" of type Z16659, but Z16660 and Z16661 mean the same thing
- alternatively use type Z40, call it "negative", because it can only be 0 or 1, not -1, 0, 1
K2: "exponent" of type Z16683, limited to the values from -1022 to 1023, including the edges
K3: "fraction" of type Z13518, which states the numerator of the fraction of the number. This denominator of the fraction is 2^exponent-53, and the number should be smaller than 2⁵³, i.e. 9,007,199,254,740,992.
- alternatively, this number could be a Z6 called binary fraction, which has to have exactly the following format: a 1, followed by a dot, followed by 52 1s or 0s, e.g. 1.1000100000100000000000000000000000000000000000000000, or a Z6 for a 13-digit hexadecimal representing the fraction.
K4: special value of type floating point special values (which also needs to be created), and can be positive zero (+0), negative zero (-0), positive infinity (+∞), negative infinity (−∞), generic "not a number" (NaN), signaling "not a number" (sNaN), quiet "not a number" (qNan), and "no special value".

Example values

Proposal 2

Value 0

{ "type": "float64", "value": "0.0" }	{ "Z1K1": "Zxxx", "ZxxxK1": "0.0" }

Proposal 3

Value +0

{
  "type": "float64",
  "sign": "positive",
  "exponent": {
    "type": "integer",
    "sign": "negative",
    "value": {
      "type": "natural number",
      "value": "1022"
    }
  },
  "fraction": {
    "type": "natural number",
    "value": "0"
  },
  "special value": "positive zero"
}

{
  "Z1K1": "Zxxx",
  "ZxxxK1": "Z16660",
  "ZxxxK2": {
    "Z1K1": "Z16683",
    "Z16683K1": "Z16662",
    "Z16683K2": {
      "Z1K1": "Z13518",
      "Z13518K1": "1022"
    }
  },
  "ZxxxK3": {
    "Z1K1": "Z13518",
    "Z13518K1": "0"
  },
  "ZxxxK4": "Zyyy"
}

Persistent objects

There are some constants meaningful to store as persistent objects, such as pi, e, (plus and minus) infinity, sNaN, qNaN, NaN, max and min values, etc.

Validator

The validator (Z19571) for option 2 ensures that:

it is a valid potential floating point format ([Nn][Aa][Nn]|[+-]?[Ii][Nn][Ff]|[+-]?(\d+\.\d*|\.?\d+)([Ee][+-]?\d+)?)
it is in canonical form (e.g. 100e100 is not in canonical form, since str(float("100e100"))="1e+102")

Identity

We need to define two kinds of identities:

Precise identity (==) - Note many operations of float64 are precisely defined
Identity with some allowed degree of error

Converting to code

Python

To convert string to float use float; on the other hand use str.

JavaScript

To convert string to float use parseFloat; on the other hand use String (note Inf and NaN should be then converted to lowercase).

Renderer

We simply use the canonical form string for English.

For Scandinavian languages Swedish and Danish we need a comma renderer so 2.66 -> 2,66.

Parsers

Same as "Converting to code" above for English.

For Scandinavian languages Swedish and Danish we need a comma parsing so 2,66 -> 2.66.

Alternatives

We can also Wikifunctions:Type proposals/float32, though neither Python nor JavaScript natively support such type.

Wikifunctions:Type_proposals/Rational_number also exists, but JavaScript doesn't natively support the type, either.

Comments

Support as generally very important. Also important to get right though, so if there are choices to make, we shouldn't rush it. --99of9 (talk) 02:36, 19 June 2024 (UTC)[reply]
How should we deal with Nans in equality functions as they are suppose to be unequal, should we treat them as unequal according to IEEE 754 or equal as there representations are equal? ScienceD90 (talk) 02:57, 22 June 2024 (UTC)[reply]
- Support I think we should have this type, although we still have to resolve this question ScienceD90 (talk) 22:10, 24 June 2024 (UTC)[reply]
I think treating them as the standard does makes the most sense? This is also what most languages tend to do. infernostars (talk) (contribs) 06:27, 21 July 2024 (UTC)[reply]
Support as non-integers generally are useful. infernostars (talk) (contribs) 06:27, 21 July 2024 (UTC)[reply]
Support I need this for a lot of functions I have created and are planning to create.--So9q (talk) 11:10, 3 August 2024 (UTC)[reply]
It is doubtful Some numeric Type(s) might be converted to float (decimal as float, scientific notation as float…), but Wikifunctions values are ultimately strings, and do not (themselves) float. I think we should do Wikifunctions:Type proposals/Rational number first (which also approximates Real numbers), then Wikifunctions:Type proposals/Decimal number (as Rational numbers, presumably a pair of integers, perhaps with the denominator being a base 10 exponent) and then (maybe) Decimal number (as float64, or float2ⁿ).--GrounderUK (talk) 10:05, 12 August 2024 (UTC)[reply]
Support, would prefer Infinity/-Infinity, but both work fine!Feeglgeef (talk) 02:30, 7 November 2024 (UTC)[reply]
I am a bit doubtful that this proposal really represents IEEE 754 floats. For example, I don't see how to represent a NaN or negative infinity in it. A string representation of such a float seems imprecise or incomplete, and wouldn't be telling about differences (i.e. is "0.1" equal to "0.1000000000000000000000000000000000000000000000001"?). The Wikipedia article on IEEE 754 describes their structure. I am wondering whether it wouldn't make more sense to stay closer to the structure of floating points, and have keys for the sign, the exponent, the fraction, and a way to represent the special values? Sorry for being a contrarian here. But otherwise I am worried that we might get problems when switching between programming languages, if we leave the interpretation of float64 values underdefined. --DVrandecic (WMF) (talk) 12:21, 7 November 2024 (UTC)[reply]
Agreed.
- The standard defines interchange formats and compliance with one of these when crossing over into code and back should be actively considered.
- I know full re-entrancy is a way down the line, but we should give that some consideration in this context too.
- That said, I’m not opposed in principle to “numeric string converted to/from float64” as an entirely separate type (that’s a string representation of “decimal number as float64” and, frankly, I’m not sure which I prefer because we can always convert such a string to a Rational number, unless it’s a special value).
GrounderUK (talk) 13:48, 7 November 2024 (UTC)[reply]

Actually I am in favor of matching IEEE 754, for programming language parity. That is what I care most about for a float type. Floats are the only primitive that you currently cannot return as a type, and what I want here is to be able to do that in a proper and standard way. Feeglgeef (talk) 13:56, 7 November 2024 (UTC)[reply]

Support lgtm. Zippybonzo (talk) 08:59, 12 November 2024 (UTC)[reply]
Support --Ameisenigel (talk) 20:44, 16 November 2024 (UTC)[reply]
I'd prefer if we had a good way of representing irrationals, like sqrt(2) and multiples, pi, i and complex numbers, and such. Though this would be difficult to implement/come up with an implementation for, I Oppose all 3 proposed options, a better way should be found. Feeglgeef (talk) 00:50, 1 December 2024 (UTC)[reply]