[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Xiaodi Wu]

On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon <scanon at apple.com> wrote:
>
>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon <scanon at apple.com> wrote:
>>>
>>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> Naive question: is it necessary to make a trade-off here? Why not an
>>> associated type Exponent that's Int for Float, Double, and Float80,
>>> allowing for something else for bignums?
>>>
>>>
>>> It’s an added (fairly minor) complexity to the API surface that confers
>>> approximately zero benefit.
>>
>> Alternatively, could `exponent` could be of type Self, just as `significand` is?
>
> IEEE 754 allows this (“If logBFormat is a floating-point format, then the following operations are homogeneous), but IMO this makes the property more awkward to use in practice.

I wonder about that. Not sure what this property would be most
commonly used for, but if it's for subsequent FP calculations, being
of type Self here seems like it would be less rather than more
awkward.

Obviously, my motivation for suggesting this is that it gets around
the arbitrary (but admittedly generous) limit of Int exponents by
requiring only that the number of bits for the exponent is less than
or equal to the number of bits used for the significand, which IMO is
more defensible.

>
> – Steve