<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 &lt;<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:scanon@apple.com" class="">scanon@apple.com</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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? &nbsp;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. &nbsp;I’m not sure if FloatingPoint is the right protocol to attach them to, but I’m not sure that it’s wrong either. &nbsp;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 :-) &nbsp; 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. &nbsp;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. &nbsp;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. &nbsp;Most programmers are at least passingly familiar with pi, but that familiarity doesn’t necessarily extend to e. &nbsp;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`. &nbsp;It’s slightly inconsistent, but might be the pragmatic solution. &nbsp;If we did this, we could be a bit more aggressive about what constants were included without worrying about being too confusing. &nbsp;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,&nbsp;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. &nbsp;Usually in arbitrary-precision libraries, these would be functions (desiredPrecision: Int) -&gt; Self, but they could also be implemented as a future that gets evaluated to the desired precision when used or something similar. &nbsp;If we add these to the protocols, I wouldn’t want to constrain the design space arbitrarily. &nbsp;The most conservative approach would be to just add them to the concrete types. &nbsp;We could also put them in a FixedWidthFloatingPoint protocol for now if necessary.</div></body></html>