Why does base not include Float128?

Internals & Design
1

I always thought it was weird that Base supports Float16 but doesn’t include Float128, even though IEE754 considers quads a basic format, while half is just an interchange format:

image

the other benefit of including 128 in base would be a more symmetric literal float syntax in julia 2.0:

1E0 # Float128
1e0 # Float64
1f0 # Float32
1F0 # Float16

instead of

1E0 # Float64
1e0 # also Float64?
1f0 # Float32
1F0 # 1 times the variable F0

it sounds like Quadmath.jl (where Float128 currently lives) is having trouble with printing due to not being a part of base, but if it were part of base we could just define a f128_str macro and print them with f128"..." like how we do Float16(...) (also, we should print big"..." for BigFloats in non-compact contexts as well, but that’s a separate issue).

we also already have an internal Base.TwicePrecision which should probably merge with DoubleFloats.jl and then get exported

2

Many modern CPUs have native instructions for half precision floating point numbers, both in the standard binary16 format, and in the Google bfloat16 format. There aren’t many commonly used CPUs with native quad precision instructions, and the intersection with the platforms actually supported by Julia is the empty set, which makes having builtin support for this format not terribly interesting.

3

Were we to change our float literals in a 2.0, IMO we would change to always e for exponent and f_n for bitwidth (e.g. 1.1e2f32 for Float32(110)). This would also have the advantage that it would also let us write 0x1.5p2f16 for Float16(6) (1.5*2^2)

4

personally, I feel like that’s a bit too busy; especially paired with juxtaposition. compare the readability of 1.1e2f32im with 1.1f2im. (or even worse with hex: 0x6.Ep1f32im)
I feel going from numeric information in 2 fields (mantissa and exponent) to 3 fields (mantissa, exponent, and size) is a significant jump

for hex float values, we could do something like we do for unsigned ints, where the number of zeros you include determines the precision:

0xF.Fp5 # Float16, 11 bit mantissa; <3 hex digits
0xF.F0000p5 # Float32, 24 bit mantissa; <7 hex digits
0xF.F00000000000p5 # Float64, 53 bit mantissa; <14 hex digits
0xF.F00000000000000000000000000p5 # Float128, 113 bit mantissa; <29 hex digits
0xF.F000000000000000000000000000p5 # BigFloat; >=29 hex digits

if we did that, making a corresponding 0o and 0b to match what we have for Uints would be a good idea too. all of them would use p to separate the exponent (written in decimal)
maybe we would also let x, o, or b for the separator mean hex, octal, or binary? (only if the mantissa is already one of 0x, 0o, or 0b, of course)
eg 0xF.FxF === 0xF.Fp15.
would make it much easier to precise binary floats:
+0b1.0000000000b00000 === reinterpret(Float16, 0b0011110000000000)