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

[Xiaodi Wu]

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 <razielim at gmail.com> wrote:

> 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 <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 29, 2016 at 1:07 PM, Stephen Canon <scanon at apple.com> wrote:
>
>>
>> On Jun 29, 2016, at 2:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On Jun 29, 2016, at 1:10 PM, Matthew Johnson <matthew at anandabits.com>
>>> 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 the case of
>>> negative numbers.
>>>
>>>
>>> Yup, I agree.  I think I originally suggested `toNearestTiesAway`.  I’m
>>> not tied to that name specifically, but we should be clear that ties go
>>> away from zero, not up.
>>>
>>
>> Agreed; `toNearestOrAwayFromZero` is the most accurate and consistent
>> description.
>>
>>
>> Worth noting that since this is the defaulted behavior, we can get away
>> with a wordy description.
>>
>
> This is really picking nits, but the most common behavior would be best as
> the first enum case, no? Maybe go roughly from most-value-preserving to
> least-value-preserving, like so:
>
> `enum RoundingRule { case toNearestOrAwayFromZero, toNearestOrEven, up,
> down, towardZero }`
>
>
>
>>
>> – Steve
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/5ddc343e/attachment.html>