Thanks for the summary of the arguments against max/min! Comments inline. > On Jun 10, 2016, at 6:51 PM, Stephen Canon <[email protected]> wrote: > > On Jun 10, 2016, at 12:38 PM, Xiaodi Wu via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> On Fri, Jun 10, 2016 at 1:24 PM, Darren Mo via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
