> 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. – Steve _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
