Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

These are already included with SE-0067, we’re just working on finishing up the implementation. /// Remainder of `self` divided by `other`. This is the IEEE 754 remainder /// operation. /// /// For finite `self` and `other`, the remainder `r` is defined by /// `r = self - other*n`,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Hello Karl and everyone else involved, an IEEE754 conform floating point implementation requires also squrt and a remainer function being provided by the respective float implementation. Shouldn't these two be also added to the FloatingPoint protocol now that the rounding functions are being

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

IMO, this is the most mathematically meaningful and semantically transparent solution. Floor and ceiling might be the popular terms but roundedUp/Down is much cleaner. > On 25 Jun 2016, at 20:55, Haravikk via swift-evolution > wrote: > > >> On 25 Jun 2016, at

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

A question, perhaps Stephen's to answer: apparently IEEE754 defaults to what we're calling `toNearestOrEven`? Should Swift be using that as the default as well? On Wed, Jun 29, 2016 at 7:41 PM, Karl Wagner wrote: > OK I’ve incorporated those small things and submitted it

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

OK I’ve incorporated those small things and submitted it for review. We’ve had an initial discussion, incorporated all the feedback, so I think it’s met the bar for a PR  https://github.com/apple/swift-evolution/pull/394 Karl > On 29 Jun 2016, at 20:20, Xiaodi Wu wrote:

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

On Wed, Jun 29, 2016 at 1:07 PM, Stephen Canon wrote: > > On Jun 29, 2016, at 2:06 PM, Xiaodi Wu wrote: > > On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jun 29, 2016, at 1:10 PM,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 29, 2016, at 1:10 PM, Matthew Johnson > wrote: > > My criticism of the 'toNearestOrGreatest' still stands though. I think > this name is misleading given

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 1:10 PM, Matthew Johnson wrote: > > My criticism of the 'toNearestOrGreatest' still stands though. I think this > name is misleading given the stated semantics. The name indicates "greater > value" not "greater magnitude" which are opposites in

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Sent from my iPhone > On Jun 29, 2016, at 12:00 PM, Stephen Canon wrote: > > >> On Jun 29, 2016, at 12:46 PM, Matthew Johnson wrote: >> >> +1 to adding robust rounding to he standard library. >> >> I’m curious why we have both `up` and `down`, but

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 1:00 PM, Stephen Canon wrote: > > >> On Jun 29, 2016, at 12:46 PM, Matthew Johnson > > wrote: >> >> +1 to adding robust rounding to he standard library. >> >> I’m curious why we have both `up`

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 29, 2016, at 12:46 PM, Matthew Johnson wrote: > > +1 to adding robust rounding to he standard library. > > I’m curious why we have both `up` and `down`, but only have `towardZero` > without `awayFromZero`. > > I’m also curious what the use case is for

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

+1 to adding robust rounding to he standard library. I’m curious why we have both `up` and `down`, but only have `towardZero` without `awayFromZero`. I’m also curious what the use case is for `toNearestOrEven` and why you don’t include `toNearestOrOdd`. I think the name of

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Updated proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 Add integral rounding functions to FloatingPoint Proposal: SE- Author: Karl Wagner

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

That’s a very good point, IMHO. - Dave Sweeris > On Jun 27, 2016, at 2:43 PM, Stephen Canon via swift-evolution > wrote: > > >> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: >> >> Seems fine to me. One addition though: some sort of

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Hadn't thought of roundUp/Down. Makes it so obvious. +10 > On 27 Jun 2016, at 18:32, Erica Sadun wrote: > > I'm with those recommending round, rounded, roundUp, roundedUp, roundDown, > roundedDown, with Remy's precision factored in as needed. > > This is usually the

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: > > Seems fine to me. One addition though: some sort of round(withPrecision: Int) I noted in another post on this thread that this doesn’t actually make any sense for FloatingPoint. I’ll flesh that out here for

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> David Sweeris wrote: > > I'm starting to come down from me earlier +1... Floor and ceiling are more > functions than properties of a number, aren't they? I agree with that. Having used various math libraries for decades now, I'd find it odd to find these as members of a floating-point type,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Seems fine to me. One addition though: some sort of round(withPrecision: Int) On Mon, Jun 27, 2016 at 12:23 Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 27, 2016, at 12:34 PM, Karl wrote: > > > On 27 Jun 2016, at 16:23, Stephen Canon

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 12:34 PM, Karl wrote: > > >> On 27 Jun 2016, at 16:23, Stephen Canon > > wrote: >> >> >>> On Jun 25, 2016, at 05:06, Karl via swift-evolution >>>

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

I'm starting to come down from me earlier +1... Floor and ceiling are more functions than properties of a number, aren't they? - Dave Sweeris > On Jun 25, 2016, at 11:48, David Sweeris via swift-evolution > wrote: > > +1 > > The only thing I'm worried about is

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

On Mon, Jun 27, 2016 at 9:34 AM Karl via swift-evolution < swift-evolution@swift.org> wrote: > On 27 Jun 2016, at 16:23, Stephen Canon wrote: > > > On Jun 25, 2016, at 05:06, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > Proposal:

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

I'm with those recommending round, rounded, roundUp, roundedUp, roundDown, roundedDown, with Remy's precision factored in as needed. This is usually the point where Dave A wanders in and explains how this can all be implemented by a single FloatingPoint protocol, with built-in properties and

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 27 Jun 2016, at 16:23, Stephen Canon wrote: > > >> On Jun 25, 2016, at 05:06, Karl via swift-evolution >> > wrote: >> >>> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 >>>

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 25, 2016, at 05:06, Karl via swift-evolution > > wrote: > >> Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 >> Karl, thanks for

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Hmm, I think they'd qualify as terms of art; I don't know that rounding to an arbitrary decimal place would be (although useful) primitive enough that they should be added in stdlib [also, to genericize over floats and doubles, how many decimal places could you usefully get?]; and grouping

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 27 Jun 2016, at 07:55, James Hillhouse wrote: > >> >> On Jun 27, 2016, at 1:53 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I disagree: in English, the nouns are floor and ceiling. That's what

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On Jun 27, 2016, at 1:53 AM, Xiaodi Wu via swift-evolution > wrote: > > I disagree: in English, the nouns are floor and ceiling. That's what they > should be called. Completely agree. > On Mon, Jun 27, 2016 at 02:41 David Hart

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

I disagree: in English, the nouns are floor and ceiling. That's what they should be called. On Mon, Jun 27, 2016 at 02:41 David Hart wrote: > Whatever the naming scheme, I would be hesitant to have the non-mutating > versions of floor and ceil have different endings, seeing

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Whatever the naming scheme, I would be hesitant to have the non-mutating versions of floor and ceil have different endings, seeing how connected they are. So: floor, ceil floored, ceiled flooring, ceiling But not a mix. > On 27 Jun 2016, at 07:13, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

On Mon, Jun 27, 2016 at 12:45 AM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > Given the API guidelines, it should be > > rounded, ceiled, floored > > for returning the rounded/ceiled/floored value and > > round(), ceil(), floor() > > would be the mutating variants.

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Given the API guidelines, it should be rounded, ceiled, floored for returning the rounded/ceiled/floored value and round(), ceil(), floor() would be the mutating variants. Question is where it's not too confusing for anyone knowing these from another language. > On Jun 25, 2016, at 9:02 PM,

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

We don't seem to have a rounded() function either as part of FloatingPoint, we should probably have these methods in the end: func rounded() -> Self func rounded(withPrecision: Int) -> Self Along with the 4 other methods proposed below. > Le 25 juin 2016 à 11:55, Haravikk via swift-evolution

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

> On 25 Jun 2016, at 11:06, Karl via swift-evolution > wrote: > > floor() and ceil(), exactly like C. ceiling() is more descriptive and is a > mathematical term of art . > nextIntegralUp() and nextIntegralDown() are

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

+1 to the proposal On Sat, 25 Jun 2016 at 17:48 David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > > Sent from my iPhone > On Jun 25, 2016, at 05:06, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > Proposal:

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Sent from my iPhone > On Jun 25, 2016, at 05:06, Karl via swift-evolution > wrote: > > Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 +1 The only thing I'm worried about is the situation where we have "x = N.M", and `x.ceiling` equals