[swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Stephen Canon]

> On Apr 14, 2016, at 11:05 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> On Apr 14, 2016, at 9:49 PM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote:
>>>> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> Provide basic constants (analogues of C's DBL_MAX, etc.)
>>>> Nice, have you considered adding pi/e and other common constants?  I’d really really like to see use of M_PI go away… :-)
>>> 
>>> That’s a reasonable suggestion.  I’m not sure if FloatingPoint is the right protocol to attach them to, but I’m not sure that it’s wrong either.  I’d be interested to hear arguments from the community either way.
>> 
>> I’m not sure where the right place is either, I just want them :-)   Seriously though, the notion of pi seems to make sense for both decimal and binary fp types, it seems base independent.
> 
> Incidentally, if you make pi and e be static members of the type, we should get a pretty fluent style, along the lines of:
> 
> 	let x = someDouble * 2 * .pi
> 
> I agree that there is a concern about deciding “which” constants to include.  I’ll let you and the numeric elite figure that out :-)

“e” is a great bike-shedding example.  While it would definitely allow a fluent style if you know what you’re looking at, I worry a little bit about readability of `Float.e` or `.e` in source.  Most programmers are at least passingly familiar with pi, but that familiarity doesn’t necessarily extend to e.  IDEs and docstrings make this palatable, of course.

I wonder if maybe we shouldn’t expose `.pi` directly, but tuck other constants behind something like `.math.e`.  It’s slightly inconsistent, but might be the pragmatic solution.  If we did this, we could be a bit more aggressive about what constants were included without worrying about being too confusing.  I would probably expose most of what’s in math.h initially:

	pi, 1/pi, e, log2(e), log10(e), log(2), log(10), sqrt(2), 1/sqrt(2)

The other question is how these play with arbitrary-precision types, if someone wants to write one that conforms to Floating Point.  Usually in arbitrary-precision libraries, these would be functions (desiredPrecision: Int) -> Self, but they could also be implemented as a future that gets evaluated to the desired precision when used or something similar.  If we add these to the protocols, I wouldn’t want to constrain the design space arbitrarily.  The most conservative approach would be to just add them to the concrete types.  We could also put them in a FixedWidthFloatingPoint protocol for now if necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160415/236101b3/attachment.html>