Currently Rust has support for the quite common floating point types f32 (single precision) and f64 (double precision), which I consider sufficient for everyday purposes.
When it comes to bigger data-structures, which require a higher dynamic range than integers can provide (raw image photography, videos, voxel data, etc.) f32 has some disadvantages. The obvious one is size: Using f32 as data type, a raw image of a 20 Mpx camera would produce 80 MB of data. The other reason is speed when it comes to real-time applications (like the computation of optical flow in computer vision)
This is why f16 (aka half float) is becoming more and more common on specialized hardware (OpenCL Specification 2.0, 18.104.22.168 Minimum List of Supported Image Formats), in imaging software (GIMP if i remember correctly) and even file formats (TIFF Technical Note 3)
I'd like so see f24 implemented for similar reasons. It finds its use where a mantissa of 11 bits (as in f16) isn't enough, but f32 is to be considered oversized.
f8 ist not so common (from my perspective), but it could find its use on embedded devices like (8-bit-)microcontrollers. An example could be a lookup table holding a gamma correction for a PWM to compensate for the nonlinearity of the human eye when perceiving brightness. Other possible uses might be per-pixel-filter-kernels.
I don't see any bigger downsides (despite some extra work of course). Platforms not supporting minifloats natively, have several options of emulation:
- Classic computation in Software using downscaled versions of existing float-libraries
- Upcasting to f32 → compute → downcasting (maybe using appropriate rounding)
- Lookup-tables and -trees for conversion and (in some cases) for computation, if memory doesn't matter that much
The relation between f32 ↔ f64 is just like f16 ↔ f32 which is just like f8 ↔ f16. So there's nothing special to learn about.
Support for f128 whould be nice, but introduces a bigger challenge as emulation would be computationally intensive. I'd rather like to see arbitrary precision ... different topic.
/edit Fixed link to TIFF paper (sorry)