> On Apr 22, 2016, at 12:09 PM, Xiaodi Wu <[email protected]> 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
> example.
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.
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
