Agree with all you said
> On 11 Jun 2016, at 02:20, Darren Mo via swift-evolution > <[email protected]> wrote: > > 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]> wrote: >>> >>>> On Fri, Jun 10, 2016 at 1:24 PM, Darren Mo via swift-evolution >>>> <[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
