> On Apr 14, 2016, at 11:05 PM, Chris Lattner <[email protected]> wrote:
>
>
>> On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> On Apr 14, 2016, at 9:49 PM, Stephen Canon <[email protected]
>> <mailto:[email protected]>> wrote:
>>>> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
