<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 11:05 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 14, 2016, at 11:01 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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 Apr 14, 2016, at 9:49 PM, Stephen Canon <<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>> wrote:<br class=""><div 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=""><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="">On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">Provide basic constants (analogues of C's DBL_MAX, etc.)</li></ul></div></div></blockquote><div class="">Nice, have you considered adding pi/e and other common constants? I’d really really like to see use of M_PI go away… :-)</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That’s a reasonable suggestion. I’m not sure if FloatingPoint is the right protocol to attach them to, but I’m not sure that it’s wrong either. I’d be interested to hear arguments from the community either way.</div></div></div></div></blockquote><div class=""><br class=""></div>I’m not sure where the right place is either, I just want them :-) Seriously though, the notion of pi seems to make sense for both decimal and binary fp types, it seems base independent.</div></div></div></blockquote><br class=""></div><div class="">Incidentally, if you make pi and e be static members of the type, we should get a pretty fluent style, along the lines of:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let x = someDouble * 2 * .pi</div><div class=""><br class=""></div><div class="">I agree that there is a concern about deciding “which” constants to include. I’ll let you and the numeric elite figure that out :-)</div></div></div></blockquote><br class=""></div><div>“e” is a great bike-shedding example. While it would definitely allow a fluent style if you know what you’re looking at, I worry a little bit about readability of `Float.e` or `.e` in source. Most programmers are at least passingly familiar with pi, but that familiarity doesn’t necessarily extend to e. IDEs and docstrings make this palatable, of course.</div><div><br class=""></div><div>I wonder if maybe we shouldn’t expose `.pi` directly, but tuck other constants behind something like `.math.e`. It’s slightly inconsistent, but might be the pragmatic solution. If we did this, we could be a bit more aggressive about what constants were included without worrying about being too confusing. I would probably expose most of what’s in math.h initially:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>pi, 1/pi, e, log2(e), log10(e), log(2), log(10), sqrt(2), 1/sqrt(2)</div><div><br class=""></div><div>The other question is how these play with arbitrary-precision types, if someone wants to write one that conforms to Floating Point. Usually in arbitrary-precision libraries, these would be functions (desiredPrecision: Int) -> Self, but they could also be implemented as a future that gets evaluated to the desired precision when used or something similar. If we add these to the protocols, I wouldn’t want to constrain the design space arbitrarily. The most conservative approach would be to just add them to the concrete types. We could also put them in a FixedWidthFloatingPoint protocol for now if necessary.</div></body></html>