<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Agree with all you said</div><div><br>On 11 Jun 2016, at 02:20, Darren Mo via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Thanks for the summary of the arguments against <font face="Menlo" style="font-size: 11px;" class="">max</font>/<font face="Menlo" style="font-size: 11px;" class="">min</font>! Comments inline.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 10, 2016, at 6:51 PM, Stephen Canon <<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jun 10, 2016, at 12:38 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 1:24 PM, Darren Mo via swift-evolution<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="">Today, one can get<span class="Apple-converted-space"> </span><font face="Menlo" style="font-size: 11px;" class="">max</font>/<font face="Menlo" style="font-size: 11px;" class="">min</font><span class="Apple-converted-space"> </span>by doing:<div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let max = Float.greatestFiniteMagnitude</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">let min = -Float.greatestFiniteMagnitude</span></font></div></div></blockquote><div class=""><br class=""></div><div class="">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`.</div></div></div></div></div></blockquote><br class=""></div><div class="">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:</div></div><div class=""><br class=""></div><div class="">– 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.</div></div></div></blockquote><div><br class=""></div><div>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 <font face="Menlo" style="font-size: 11px;" class="">Float.infinity</font> being greater than <font face="Menlo" style="font-size: 11px;" class="">Float.max</font>. 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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">– The proposed `.min` doesn't align with the meaning of the "float-min-thing” in most other major languages:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In C, FLT_MIN is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In C++, std::numeric_limits<float>::min() is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In Python, sys.float_info.min is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In C#, .minValue is documented as “the smallest possible value”, but is actually the value you want, rather than the documented –infinity.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In Java, MIN_VALUE is the smallest positive value (including subnormals)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In Ruby, MIN is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In R, double.xmin is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>In MATLAB, realmin is the smallest positive normal</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Actually, Rust is the only language I know of where `MIN` is the value you want *and* correctly documented as such.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>I think if we have <font face="Menlo" style="font-size: 11px;" class="">.min</font> <i class="">*and*</i> <font face="Menlo" style="font-size: 11px;" class="">.leastNormalMagnitude</font> <i class="">*and*</i> <font face="Menlo" style="font-size: 11px;" class="">.leastNonzeroMagnitude</font>, then there is no ambiguity or confusion. Moreover, I would suspect most people naturally think of <font face="Menlo" style="font-size: 11px;" class="">.min</font> 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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">– 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.</div></div></div></blockquote><div><br class=""></div><div>What is an example of this?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">– Steve</div></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>