[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols
scanon at apple.com
Fri Apr 22 10:40:58 CDT 2016
> On Apr 22, 2016, at 11:29 AM, David Sweeris <davesweeris at mac.com> wrote:
>> On Apr 22, 2016, at 9:56 AM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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.
> So you admit the benefit isn’t *actually* zero? :-)
> Yes, it does add a small bit of complexity to the API’s surface, but it's on a part of the surface that I don’t think people look at very much. How often are people extracting a float’s exponent? Plus, I suspect there’s a fair bit of overlap between the group of people who even know what `.exponent` would get used for, and those who’d get a warm fuzzy feeling from seeing that the standard library has baked-in, low-level support for bignum / arbitrary precision types.
> Embrace the warm fuzzies… make exponent be an associated type.
> - Dave Sweeris (who, despite the light-hearted tone, thinks this is actually pretty important)
The current design does not prevent bignum / arbitrary precision types. It prevents soft-float types with ridiculously large exponent ranges, but such enormous numbers are generally better modeled by either a logarithmic number system or level-index arithmetic.
Making exponent an associated type makes implementing any future heterogeneous operations (including generic conversions) more complex. This is a real cost, for a dubious theoretical benefit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution