On Apr 15, 2016, at 8:20 AM, Stephen Canon <[email protected]> wrote:
>>
>> 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`.
Yes, I think this is a great approach. In my (totally limited and arbitrary)
experience, Pi is used orders of magnitude more commonly than other non-trivial
constants.
This is another situation where I wish we had real submodules and generic
properties already. At that point, we could these constants defined in the
Math submodule, and even give them unicode aliases like π. Then you’d get this
sort of behavior:
let _ = 2*.pi*b // works everywhere.
let _ = y + Math.e + .pi // works everywhere, for all the weird constants you
want to dump into the math module.
let _ = 2 * Math.π * b // works everywhere.
func doMathStuff() { // some local scode
import Math
let _ = y + e + .pi // works because we imported Math.
let _ = 2 * π * b // works because we imported Math.
}
That said, we don’t have those features, so perhaps the discussion should be
scoped to just adding the pi member for swift 3.
> 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.
It would be unfortunate if these weren’t supported by (e.g.) the binary FP
protocol at least, since that would defeat code trying to use type-generic FP
algorithms.
Does the rest of your design scale to arbitrary precision types? Is arbitrary
precision FP used in any common or important domain? If not, it seems worth
throwing under the bus to get better utility for the types that non-specialists
actually use in practice.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
