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

[Xiaodi Wu]

On Fri, Apr 22, 2016 at 11:09 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon <scanon at apple.com> wrote:
>>
>>> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> 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.
>>
>> 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.

To expand, the hypothetical use case I'm trying to leave open is this:
suppose I want to implement a Float1024 type with 79 exponent bits and
944 fraction bits. Could I conform it to BinaryFloatingPoint? As
currently proposed, no. What would make it possible would be
`exponent` of type Self, pushing down RawSignificand to
BinaryFloatingPoint, and using that associated type for both
`exponentBitPattern` and `significandBitPattern` (perhaps renaming it
RawBitPattern).

>>
>> – Steve