# Why does base not include Float128?

**URL:** <https://discourse.julialang.org/t/why-does-base-not-include-float128/139092>\
**Category:** Internals & Design\
**Tags:** float\
**Created:** [August 28, 2026, 10:49pm UTC](https://discourse.julialang.org/t/why-does-base-not-include-float128/139092 "2026-08-28T22:49:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![rokke](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rokke/32/222691_2.png) [@rokke](https://discourse.julialang.org/u/rokke)\
**Post date:** [August 28, 2026, 10:49pm UTC](https://discourse.julialang.org/t/why-does-base-not-include-float128/139092/1 "2026-08-28T22:49:04Z")

</div>

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](https://global.discourse-cdn.com/julialang/original/3X/a/9/a9750d522071f7d786b728f0735f7cf5259e327c.png)](https://en.wikipedia.org/wiki/IEEE_754#Basic_and_interchange_formats)

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

```julia-auto
1E0 # Float128
1e0 # Float64
1f0 # Float32
1F0 # Float16

```

instead of

```julia-auto
1E0 # Float64
1e0 # also Float64?
1f0 # Float32
1F0 # 1 times the variable F0

```

it sounds like [`Quadmath.jl`](https://github.com/JuliaMath/Quadmath.jl) (where Float128 currently lives) is having [trouble with printing](https://github.com/JuliaMath/Quadmath.jl/pull/92#issuecomment-3344768859) 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 `BigFloat`s 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`](https://github.com/JuliaMath/DoubleFloats.jl) and then get exported

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [August 28, 2026, 11:39pm UTC](https://discourse.julialang.org/t/why-does-base-not-include-float128/139092/2 "2026-08-28T23:39:46Z")

</div>

Many modern CPUs have native instructions for half precision floating point numbers, both in the standard [binary16 format](https://en.wikipedia.org/wiki/Half-precision_floating-point_format), and in the Google [bfloat16 format](https://en.wikipedia.org/wiki/Bfloat16_floating-point_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.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [August 29, 2026, 12:18am UTC](https://discourse.julialang.org/t/why-does-base-not-include-float128/139092/3 "2026-08-29T00:18:49Z")

</div>

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`)

---

<div class="post-metadata">

**Author:** ![rokke](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rokke/32/222691_2.png) [@rokke](https://discourse.julialang.org/u/rokke)\
**Post date:** [August 29, 2026, 12:38am UTC](https://discourse.julialang.org/t/why-does-base-not-include-float128/139092/4 "2026-08-29T00:38:55Z")

</div>

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:

```julia-auto
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 `Uint`s 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 `0x`, `0o`, or `0b`, of course; otherwise `b` looks like hex)  
eg `0xF.FxF === 0xF.Fp15`.  
would make it much easier to precise binary floats:  
`+0b1.0000000000b00000 === reinterpret(Float16, 0b0011110000000000)`