Generalised tests on interesting values for all primitives

[sloorush]

          They're not listed anywhere, no. But maybe we should write them on the wiki somewhere. The interpreter only allows pocket types to store int8_t,  int16_t and in32_t integer values (besides bit packed boolean values), so something that would fit in uint16_t but not in uint8_t would end up with eltype int32_t. Likewise, something that would fit in uint32_t but not in int32_t would end up as an aplfloat32 (double).

So, for interesting integral values: -2*(n-1) and ¯1+2*(n-1) (where n is 8, 16, 32, 64). Maybe one value either side of them. And 0 and 1. See: https://en.cppreference.com/w/c/types/limits, https://learn.microsoft.com/en-us/cpp/cpp/integer-limits?view=msvc-170, https://learn.microsoft.com/en-us/cpp/cpp/floating-limits?view=msvc-170

The value 9007199254740992 was very clever: it's the first integer whose float representation in IEEE-754 is not unique (https://en.wikipedia.org/w/index.php?title=Double-precision_floating-point_format), since doubles have 52 bits of precision and 2*53 is 9007199254740992. So:

• [0-9007199254740988]: all values stored as a unique bit representation
• 9007199254740989 is stored as: 0x433ffffffffffffd (unique: this bit representation only ever means this value)
• 9007199254740990 is stored as: 0x433ffffffffffffe (unique: this bit representation only ever means this value)
• 9007199254740991 is stored as: 0x433fffffffffffff (unique: this bit representation only ever means this value)
• 9007199254740992 is stored as: 0x4340000000000000 (NOT unique: also represents 9007199254740993)
• 9007199254740993 is stored as: 0x4340000000000000 (NOT unique: also represents 9007199254740992)
• 9007199254740994 is stored as: 0x4340000000000001 (unique: this bit representation only ever means this value)
• 9007199254740995 is stored as: 0x4340000000000002 (NOT unique: also represents 9007199254740996)
• 9007199254740996 is stored as: 0x4340000000000002 (NOT unique: also represents 9007199254740995)

So, it's very clever to see how the interpreter handles 9007199254740992 because it will look to the interpreter the same value as 9007199254740993.

Similarly for negative values: negation just switches the sign bit, so 0x434 exponent part of the bit representation (0b010000110100) just changes to 0xc34 (0b110000110100):

• [0-¯9007199254740988]: all values stored as a unique bit representation
• ¯9007199254740989 is stored as: 0xc33ffffffffffffd (unique: this bit representation only ever means this value)
• ¯9007199254740990 is stored as: 0xc33ffffffffffffe (unique: this bit representation only ever means this value)
• ¯9007199254740991 is stored as: 0xc33fffffffffffff (unique: this bit representation only ever means this value)
• ¯9007199254740992 is stored as: 0xc340000000000000 (NOT unique: also represents 9007199254740993)
• ¯9007199254740993 is stored as: 0xc340000000000000 (NOT unique: also represents 9007199254740992)
• ¯9007199254740994 is stored as: 0xc340000000000001 (unique: this bit representation only ever means this value)
• ¯9007199254740995 is stored as: 0xc340000000000002 (NOT unique: also represents 9007199254740996)
• ¯9007199254740996 is stored as: 0xc340000000000002 (NOT unique: also represents 9007199254740995)

Off the top of my head, I can't think of any other "clever" value like this for doubles, but there will be similar number for decfs when it can store the last integer uniquely before it runs out of precision. I Imagine that's 2*111 since decfs have 110 bits of precision (https://en.wikipedia.org/wiki/Decimal128_floating-point_format). But I'd check that for sure...

(FYI, I have a little program I made that can print double and float representations. I'll put it on github...)

Originally posted by @definitelyprobably in #76 (comment)

[sloorush]

• Check for scalar booleans #112 might be related