[Review] SE-0113: Add integral rounding functions to FloatingPoint

Evolution Announcements
1

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

  swift-evolution/0113-rounding-functions-on-floatingpoint.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

Nice and swifty, +1

This is a nice addition to the standard library that removes a common
reason C libraries had to be imported.

···

On Thu, Jun 30, 2016 at 11:02 PM Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint"
begins now and runs through July 5. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

3

What is your evaluation of the proposal?

I think it’s good to have this functionality in the standard library, but it seems a bit inconsistent with other Swift math operators which are declared as global functions such as abs, max, +, -, /, *, %, etc.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, I believe that it would be useful to have these methods.

Does this proposal fit well with the feel and direction of Swift?

As I mentioned before, it seems to be a departure from Swift’s other math operators. I think global functions such as floor(), ceil() and round() would be more consistent.

···

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

4

[Proposal: swift-evolution/0113-rounding-functions-on-floatingpoint.md at master · apple/swift-evolution · GitHub ]

Just wondering, why no 'awayFromZero' case?

Jordan

5

* What is your evaluation of the proposal?
+ 1
        * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
        * Does this proposal fit well with the feel and direction of Swift?
Yes.
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick reading

···

On Fri, Jul 1, 2016 at 2:02 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint"
begins now and runs through July 5. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

        https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:

        * What is your evaluation of the proposal?
        * Is the problem being addressed significant enough to warrant a
change to Swift?
        * Does this proposal fit well with the feel and direction of Swift?
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

   * What is your evaluation of the proposal?

It is an improvement but would it be even better if the return type was Int (or possibly type inferred to Int16 etc.). If a float is really desired it can be initialised from the Int (or it could even infer float result is required).

   * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, reduces reliance on C APIs. API also clearer about semantics.

   * Does this proposal fit well with the feel and direction of Swift?

Yes

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read and a quick look at earlier discussion linked from proposal.

Joseph

7

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

In principle +1, but I’d prefer if the proposal also included rounding with a specified precision. I.e.

func rounded(_ rule: RoundingRule = toNearestOrAwayFromZero, decimalPlaces digits: Int = 0) -> Self

  * Is the problem being addressed significant enough to warrant a change to Swift?

yes

  * Does this proposal fit well with the feel and direction of Swift?

yes

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

yes. I like how the proposal accounts for the rounding rule. However, what is missing is rounding with specified precision

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

glance

8

+1. These additions are appreciated and well thought out.

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

+1

  * Is the problem being addressed significant enough to warrant a change to Swift?

yes. They ease the burden on usage of swift.

  * Does this proposal fit well with the feel and direction of Swift?

y

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

They depart from the well-known and common floor() and ceil(), which may be confusing to some users. On balance, however, I believe these approach taken is cleaner and should be adopted.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I followed the mailing list discussion and carefully read the proposal a number of times.

James

···

On Jun 30, 2016, at 11:02 PM, Chris Lattner <clattner@apple.com> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

9

Hello Swift community,

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

   * What is your evaluation of the proposal?

+1. Small, simple, and "Swifty"

Regarding the proposal itself (as opposed to the proposed solution):
Rounding to a specific precision (e.g. 2 decimals) was discussed prior to the proposal and could be mentioned under Alternatives Considered with an explanation of why it was excluded form the proposal.

   * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, probably. It's a small change for a small problem

   * Does this proposal fit well with the feel and direction of Swift?

Yes. The proposed solution feels more at home in Swift than what's currently there and fits the general direction of preferring member functions over free functions.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used the floor and ceil functions in various C based languages. Those fit in with the style of C, and these fit in with the style and naming conventions of Swift.

I've also used Math.Round in Visual Basic a long time ago (don't judge me). It allows for two rounding modes (AwayFromZero and ToEven (bankers rounding)). I had to look that up because I didn't remember how it actually worked.

In each case (including this proposal) I feel that the various solutions feel right at home in their various contexts.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal. Skimmed the discussion.

···

Sent from my iPad

On 1 Jul 2016, at 08:02, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

  * What is your evaluation of the proposal?

Looks good to me.

`RoundingRule.toNearestOrEven` is a fine name, but I would like the documentation to mention the term "bankers' rounding", a traditional term which Foundation uses for the same algorithm. (Actually, it might be a good idea to talk to the Foundation guys and see if you can get them to implement `toNearestOrEven` and then replace `NSDecimalNumber.RoundingMode` with `Swift.RoundingRule` in their Swift APIs. This would undoubtedly require some coordination of raw values and so on.)

On this question:

…although we may consider suppressing the imported, global-level C functions, or perhaps automatically migrating them to the new instance-method calls.

I would suggest that we suppress the C functions and replace them with generic versions which take a FloatingPoint parameter and call through to `rounded(_:)`. If people want to use the terms of art here, there's no strong reason to fight them on it.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes; we want to cover all of IEEE 754, and this is a piece of that.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. This is a very elegant way to handle rounding.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I can't believe how many languages have slavishly copied C without trying to improve on it.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, a little bit of research on Decimal's rounding support.

···

--
Brent Royal-Gordon
Architechies

11

This is a common thought, but it's precisely backwards from a numerics and pragmatics perspective. The result is always representable as `Self`, and generally not representable in any fixed-width integer type. If you have the version that produces `Self`, getting an integer falls out trivially:

  let y = Int(x.rounded(.up)) [1]

But if you only have the version that produces an integer result, you’re stuck with a much more complex workaround when you actually need the result as `Self` (which is more common than you think). In the best case scenario, where `Int` is bigger than the significand of `Self`, it’s not *too* bad, but still requires at least a conditional and two conversions. In the bad scenario, a floating-point type whose significand doesn’t fit in `Int`, you end up needing to write all the rounding logic yourself.

The idea of also having a set of Integer inits that round has been mentioned once or twice in the past:

  let y = Int(roundedUp: x)

I’m not sure if that’s really any cleaner than [1], but it could certainly be considered as another proposal.

– Steve

···

On Jul 1, 2016, at 7:44 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org> wrote:

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

  * What is your evaluation of the proposal?

It is an improvement but would it be even better if the return type was Int (or possibly type inferred to Int16 etc.). If a float is really desired it can be initialised from the Int (or it could even infer float result is required).

12

It’s not defined or required by IEEE 754. The others are. I wouldn’t be opposed to adding some other rounding modes, but the IEEE 754 set is as good as any as a starting point.

– Steve

···

On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md ]

Just wondering, why no 'awayFromZero' case?

13

Note under the latest floating point and integer protocol proposals the
operators you outlined are basically overlays of the protocol functions
even abs is replaced with magnitude on a protocol. Sorry not in a situation
to link out to the proposals.

···

On Fri, Jul 1, 2016 at 7:51 AM Brad Hilton via swift-evolution < swift-evolution@swift.org> wrote:

> What is your evaluation of the proposal?
I think it’s good to have this functionality in the standard library, but
it seems a bit inconsistent with other Swift math operators which are
declared as global functions such as abs, max, +, -, /, *, %, etc.
> Is the problem being addressed significant enough to warrant a change to
Swift?
Yes, I believe that it would be useful to have these methods.
> Does this proposal fit well with the feel and direction of Swift?
As I mentioned before, it seems to be a departure from Swift’s other math
operators. I think global functions such as floor(), ceil() and round()
would be more consistent.

> Hello Swift community,
>
> The review of "SE-0113: Add integral rounding functions to
FloatingPoint" begins now and runs through July 5. The proposal is
available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md
>
> Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and contribute to the direction of Swift.
When writing your review, here are some questions you might want to answer
in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change
to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

We could perhaps change the existing Int(FloatingPoint) initialisers to take a RoundingRule with a default argument. Currently I believe they are equivalent to floor, but that’s a documentation comment and isn’t explicit in the API itself.

Karl

···

On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution <swift-evolution@swift.org> wrote:

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

  * What is your evaluation of the proposal?

It is an improvement but would it be even better if the return type was Int (or possibly type inferred to Int16 etc.). If a float is really desired it can be initialised from the Int (or it could even infer float result is required).

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, reduces reliance on C APIs. API also clearer about semantics.

  * Does this proposal fit well with the feel and direction of Swift?

Yes

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read and a quick look at earlier discussion linked from proposal.

Joseph
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

15

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

In principle +1, but I’d prefer if the proposal also included rounding with a specified precision. I.e.

func rounded(_ rule: RoundingRule = toNearestOrAwayFromZero, decimalPlaces digits: Int = 0) -> Self

Rounding with specified precision was discussed, but excluded from the proposal. It could be mentioned in the Alternatives Considered why it's not part of this proposal.

···

On 1 Jul 2016, at 14:13, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

  * Is the problem being addressed significant enough to warrant a change to Swift?

yes

  * Does this proposal fit well with the feel and direction of Swift?

yes

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

yes. I like how the proposal accounts for the rounding rule. However, what is missing is rounding with specified precision

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

glance

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

Next time I will search first: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022697.html\. Thanks, Steve.

Jordan

···

On Jul 1, 2016, at 10:13, Stephen Canon <scanon@apple.com> wrote:

On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md ]

Just wondering, why no 'awayFromZero' case?

It’s not defined or required by IEEE 754. The others are. I wouldn’t be opposed to adding some other rounding modes, but the IEEE 754 set is as good as any as a starting point.

17

I'm hearing a lot of "Wouldn't it be nice if"s, for items falling outside IEEE 754. Could we have a native Math module that offered such niceties under a separate umbrella proposal? Would it be too cluttery to allow things like Double.tau, etc via a Math.Double extension or however that might work?

-- E, who abides by Canon law

···

On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md ]

Just wondering, why no 'awayFromZero' case?

It’s not defined or required by IEEE 754. The others are. I wouldn’t be opposed to adding some other rounding modes, but the IEEE 754 set is as good as any as a starting point.

18

trunc( ), not floor (matching the behavior of C-family conversions to integer).

···

On Jul 1, 2016, at 1:14 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

On 1 Jul 2016, at 13:44, Joseph Lord via swift-evolution <swift-evolution@swift.org> wrote:

The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

* What is your evaluation of the proposal?

It is an improvement but would it be even better if the return type was Int (or possibly type inferred to Int16 etc.). If a float is really desired it can be initialised from the Int (or it could even infer float result is required).

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes, reduces reliance on C APIs. API also clearer about semantics.

* Does this proposal fit well with the feel and direction of Swift?

Yes

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read and a quick look at earlier discussion linked from proposal.

Joseph
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

We could perhaps change the existing Int(FloatingPoint) initialisers to take a RoundingRule with a default argument. Currently I believe they are equivalent to floor, but that’s a documentation comment and isn’t explicit in the API itself.

19

I expect we will at some point in the future!

For constants specifically, while I would still want to keep them out of the top-level namespace on the types, I think it would make a lot of sense to have something like Double.Constant.xxx which could swallow pretty much anything that there’s a reasonable argument to justify.

We also wouldn’t want these to be a requirement of FloatingPoint, unless there were default implementations to *compute* all of them to full precision, to avoid placing too high of a burden on folks who want to conform to the protocol.

That would be pretty solidly in the “post swift 3” pile, however.

···

On Jul 1, 2016, at 1:20 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md ]

Just wondering, why no 'awayFromZero' case?

It’s not defined or required by IEEE 754. The others are. I wouldn’t be opposed to adding some other rounding modes, but the IEEE 754 set is as good as any as a starting point.

I'm hearing a lot of "Wouldn't it be nice if"s, for items falling outside IEEE 754. Could we have a native Math module that offered such niceties under a separate umbrella proposal? Would it be too cluttery to allow things like Double.tau, etc via a Math.Double extension or however that might work?

20

Given that 2 * pi is always as precise as pi itself, I really can't
understand the clamor for such a constant in the stdlib. It can be defined
both correctly and trivially by anyone who wants it.

···

On Fri, Jul 1, 2016 at 12:21 Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

On Jul 1, 2016, at 11:13 AM, Stephen Canon via swift-evolution < > swift-evolution@swift.org> wrote:

On Jul 1, 2016, at 1:11 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote:

[Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md
]

Just wondering, why no 'awayFromZero' case?

It’s not defined or required by IEEE 754. The others are. I wouldn’t be
opposed to adding some other rounding modes, but the IEEE 754 set is as
good as any as a starting point.

I'm hearing a lot of "Wouldn't it be nice if"s, for items falling outside
IEEE 754. Could we have a native Math module that offered such niceties
under a separate umbrella proposal? Would it be too cluttery to allow
things like Double.tau, etc via a Math.Double extension or however that
might work?

-- E, who abides by Canon law

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution