Add floating-point internal bit representation to TypeInfo #1139
Conversation
|
So I was playing around with this a bit and in terms of usage, it may be slightly nicer to instead expose a userland function in std which returns a comptime int. The bitwise shifts to extract the mantissa/exponent need to otherwise perform an explicit cast to a Log2Int of the suitable size anyway. Thoughts on this approach vs. the current? |
|
An important thing also is the bias (often represented as a negative number despite being 'positive'). So that probably needs to be added. I was using that today when implementing atof. |
|
The bias can be computed directly from the exponent bits for any floating point type via |
|
Fair enough |
|
If I would lean towards the userland std lib function approach. |
|
Alright, sounds good. Will open a new PR at some stage with equivalent functions. Will modify some of the existing math functions while I'm at it for comparison. |
This makes writing floating-point generic code easier if it works with the internal bit representation.
Note that 80-bit extended precision floats may have a slightly different internal representation to all other types and according to IEEE this may be implementation defined. It currently is set to the most likely representation. We typically don't accept long doubles in the current math functions so can see how this plays out in practice, special casing if needed.
https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format