[swift-evolution] Add max/min to floating point types

[David Hart]

Agree with all you said

> On 11 Jun 2016, at 02:20, Darren Mo via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks for the summary of the arguments against max/min! Comments inline.
> 
>> On Jun 10, 2016, at 6:51 PM, Stephen Canon <scanon at apple.com> wrote:
>> 
>>> On Jun 10, 2016, at 12:38 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> On Fri, Jun 10, 2016 at 1:24 PM, Darren Mo via swift-evolution <swift-evolution at swift.org> wrote:
>>>> Today, one can get max/min by doing:
>>>> 
>>>> let max = Float.greatestFiniteMagnitude
>>>> let min = -Float.greatestFiniteMagnitude
>>> 
>>> On review of the proposal for the new FloatingPoint, I too commented on the lack of `max` and `min`. You've pointed out the issue with infinity. But also, FLT_MIN (from your local friendly C universe and available in Swift, obviously) is actually the smallest representable positive value, so `Float.min` is of ambiguous meaning. It was therefore decided not to use those words `max` and `min`.
>> 
>> It’s worth noting that this issue has been pretty extensively discussed both on- and off-list.  Although convenience is good, the objections to the ambiguity of `.max` and `.min` would be *very* hard to overcome:
>> 
>> – They’re not actually the maximum and minimum values of the type.  In particular, that `max(Float.infinity, .max)` wouldn’t be `Float.max` is pretty seriously confusing.
> 
> Infinity is a special value. I would argue that people who use infinity know exactly what they are doing and would not be thrown by Float.infinity being greater than Float.max. I am willing to bet that most regular users don’t even know that infinity can be represented since it is rarely needed in real-world usage.
> 
>> 
>> – The proposed `.min` doesn't align with the meaning of the "float-min-thing” in most other major languages:
>> 
>> 	In C, FLT_MIN is the smallest positive normal
>> 	In C++, std::numeric_limits<float>::min() is the smallest positive normal
>> 	In Python, sys.float_info.min is the smallest positive normal
>> 	In C#, .minValue is documented as “the smallest possible value”, but is actually the value you want, rather than the documented –infinity.
>> 	In Java, MIN_VALUE is the smallest positive value (including subnormals)
>> 	In Ruby, MIN is the smallest positive normal
>> 	In R, double.xmin is the smallest positive normal
>> 	In MATLAB, realmin is the smallest positive normal
>> 	Actually, Rust is the only language I know of where `MIN` is the value you want *and* correctly documented as such.
>> 
>> All that’s not to say that Swift can’t do this, but there’s a lot of opportunity for confusion on this point, and having a very explicit name isn’t really a bad thing.
> 
> I think if we have .min *and* .leastNormalMagnitude *and* .leastNonzeroMagnitude, then there is no ambiguity or confusion. Moreover, I would suspect most people naturally think of .min as the most-negative number that can be represented (c.f. the top search results for “FLT_MIN”). If this is true, then we have an opportunity to align the language with the user’s true desires instead of just following precedent.
> 
>> 
>> – There is also some concern that having `.min` and `.max` with the same names as on Integer types would lead people to try to use them the same way in code, which generally isn’t going to work the way users expect.
> 
> What is an example of this?
> 
>> 
>> – Steve
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160611/22ff7d16/attachment.html>