On Fri, Apr 22, 2016 at 11:09 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon <sca...@apple.com> wrote: >> >>> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon <sca...@apple.com> wrote: >>>> >>>>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>>> >>>>> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon <sca...@apple.com> wrote: >>>>>> >>>>>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu <xiaodi...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
