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

[Stephen Canon]

> 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.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160422/c8d6c6a6/attachment.html>