<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="">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><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><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><br class=""></div><div><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=""><div class="">Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future. It would be great to avoid this in your design.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Interesting. Both are definitely useful, but Type(1).ulp is sufficiently simple that only having the instance member may be good enough. Otherwise, ulpOfOne or similar could work.</div></div></div></div></blockquote><div><br class=""></div>Either of those work for me.</div><div><br class=""></div><div><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=""><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I’m certainly not a floating point guru, but I would have expected significant to be of type RawSignificand, and thought that the significant of a nan would return its payload. Does this approach make sense?</div><div class=""><br class=""></div><div class="">… later: I see that you have this on the binary FP type, so I assume there is a good reason for this :-)</div></div></div></blockquote><div class=""><br class=""></div><div class="">Both are useful to have in practice. I have been attempting to keep the assumptions about representation to a minimum in the top-level FloatingPoint protocol.</div></div></div></div></blockquote><div><br class=""></div>Makes sense!</div><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=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I’m used to this being called a “Denormal”, but I suspect that “subnormal” is the actually right name? Maybe it would be useful to mention the “frequently known as denormal” in the comment, like you did with mantissa earlier.</div></div></div></blockquote><br class=""></div><div class="">Yes, “subnormal” is the preferred IEEE 754 terminology, but I’ll add a note referencing “denormal” as well.</div></div></div></blockquote><br class=""></div><div>Thanks!</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>