Closed Anaminus closed 4 years ago
Here is a non-exhaustive list of languages that respond to the following prompt:
Format 0.25 to one decimal place. Expects either "0.2" or "0.3".
Point-two camp:
Point-three camp:
#### float A floating point number displayed as bits. Value: +0_0 Value: -124_0 Value: -1020_0 Value: +128_4789895 Value: +1024_2570638124657944 Value: +Inf Value: -Inf Value: NaN Values have the general form: +EEEE_SSSS `+` represents the sign bit, which is either `+` for positive, or `-` for negative. As a special case, a value of 0 (where the exponent and significand are both 0) is always positive regardless of the sign bit. `EEEE` represents the exponent bits as a base 10 unsigned integer. `SSSS` represents the significand bits as a base 10 unsigned integer. The special cases of infinity and NaN are represented by `+Inf`, `-Inf` and `NaN`.
This produces an exact representation of a float. However, it's not very readable.
Instead of testing for direct equality, a golden file is divided into fragments.
A fragment is marked by $TYPE(...)
, where TYPE
is some defined fragment type. The text between the parentheses is compared depending on the fragment type. Text outside fragments is compared literally as usual.
Fragments cannot be escaped. Instead, tests should avoid producing literals that contain fragment markers.
The following fragments are then defined:
Type | Description |
---|---|
FLOAT |
Text is parsed and compared as a floating-point number. |
As long as a generator encodes enough digits to reproduce a value, the exact text does not matter.
Golden files are now JSON, which are compared semantically. Floats that print differently but represent the same value are now compared correctly.
When formatting floats, the rounding of decimals depends on the implementation. The two common methods are half-away-from-zero (HAFZ), and half-to-even (HTE), based on standards defined in the floating-point specification.
Roblox appears to use HAFZ, as suggested by the following snippet:
On the other hand, a similar snippet in Go prints a different result, where HTE is used:
This difference interacts poorly with golden files, which require the exact matching of text. One rounding method can be chosen over the other for the golden file spec, but it then becomes difficult for implementations that use the opposite method to produce correct results.