On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon <[email protected]> wrote:
>
>> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu <[email protected]> wrote:
>>
>> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon <[email protected]> wrote:
>>>
>>>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu <[email protected]> wrote:
>>>>
>>>> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon <[email protected]> wrote:
>>>>>
>>>>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu <[email protected]> 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.

>
> – Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to