[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols
scanon at apple.com
Fri Apr 22 11:28:46 CDT 2016
> On Apr 22, 2016, at 12:09 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> This runs into exactly the same issues; in the (extremely rare) cases where such enormous exponents are used, they tend to be coupled with surprisingly modest significands, so I don’t think this fixes anything.
>> There was some discussion of such formats on the IEEE 754 list circa 2007 w.r.t. edge cases of some of the usual library functions that break down when enormous exponent ranges are paired with small significands, but (much like this discussion) it was almost entirely theoretical. IIRC only one list member had actually ever had occasion to use such a format.
> Sorry, to be clear, I'm not arguing for expanding FloatingPoint to
> support pairing large exponents with small significands. In my mind,
> it's a bonus and not a drawback if exponent bits are restricted to be
> less than or equal to significand bits. It elegantly avoids the
> excessiveness of returning exponents of type Int for Float, for
Ah, in that case the rationale for the current state of affairs is much easier to explain:
1. `Int` is the preferred type for integer quantities in Swift. It’s not excessive to use for the exponent of `Float`, even though only 9 bits are required.
2. It turns out that most of the operations you want to do on `exponent` are fundamentally integer operations, so it makes sense for it to be an integer type.
3. If `exponent` has type `Self`, then `init(sign, exponent, significand)` needs to define and handle non-integral values of `exponent`, which is a mess. The “is this floating-point value integral” test is quite non-trivial on some hardware platforms, and more expensive than one would like it to be even when it is trivial.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution