<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=""><div class="">Where does your RawSignificand input come from? Is that really the type that you want?</div><div class=""><br class=""></div><div class="">I don’t think you really need very much boilerplate at all here.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 26, 2016, at 7:30 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" class="">jens@bitcycle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I understand.<div class="">It's just very tempting to try and use the new static computed properties for eg 23 and 52 etc.</div><div class="">I guess I'll just have to write a lot of boilerplate, or perhaps a protocol that is just implemented by Double and Float (that will be very similar to BinaryFloatingPoint in a lot of ways).</div><div class="">/Jens</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:25 AM, Stephen Canon <span dir="ltr" class=""><<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">This doesn’t really scale up very well, though. BinaryFloatingPoint needs to also be able to model e.g. Float2048 or similar; we generally don't want to require that RawExponent to be the same type as RawSignificand (which I think is what you’re really suggesting), because in typical bignum usage significands are much larger than exponents.</div><div class=""><br class=""></div><div class="">It sounds like maybe you actually want to be operating directly on bitPatterns, rather than the abstract fields of the types.</div><div class=""><br class=""></div><div class="">– Steve</div><div class=""><div class="h5"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 26, 2016, at 7:21 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank" class="">jens@bitcycle.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Oh, to more directly answer your question: I don't like having to create a UInt (UInt64) value when all my bit manipulaton code happens in UInt32 (for Float) for example.<div class=""><br class=""></div><div class="">The most probable context for using these computed properties and types of BinaryFloatingPoint is one in which specific fixed width types really matters a lot (look at the name of the protocol and the properties and assocated types we are talking about).</div><div class=""><br class=""></div><div class="">/Jens</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <span dir="ltr" class=""><<a href="mailto:jens@bitcycle.com" target="_blank" class="">jens@bitcycle.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Reason for asking is that I have this:<div class=""><br class=""><div class=""><div class="">extension Double {</div><div class=""> init(unitRangeFromRawSignifica<wbr class="">nd s: RawSignificand) {</div><div class=""> let bitPattern = s | (1023 << 52)</div><div class=""> self = unsafeBitCast(bitPattern, to: Double.self) - 1.0</div><div class=""> }</div><div class="">}</div><div class="">extension Float {</div><div class=""> init(unitRangeFromRawSignifica<wbr class="">nd s: RawSignificand) {</div><div class=""> let bitPattern = s | (127 << 23)</div><div class=""> self = unsafeBitCast(bitPattern, to: Float.self) - 1.0</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">But they would be better as:</div><div class="">extension BinaryFloatingPoint {</div><div class=""> init(unitRangeFromRawSignifica<wbr class="">nd s: RawSignificand) {</div><div class=""> ... problems here, have to try casting things into RawSignificand's type ...</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div></div><div class="">Please have a go at that and perhaps you see what I mean or you will come up with a nice solution that I have missed. (Speed is very important btw.)</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">/Jens</div><div class=""><br class=""></div></font></span></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <span dir="ltr" class=""><<a href="mailto:scanon@apple.com" target="_blank" class="">scanon@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:<br class="">
><br class="">
> I can understand why<br class="">
> Double.RawSignificand is UInt64<br class="">
> and<br class="">
> Float.RawSignificand is UInt32<br class="">
><br class="">
> But I can't understand why both<br class="">
> Double.RawExponent<br class="">
> and<br class="">
> Float.RawExponent<br class="">
> should be UInt.<br class="">
><br class="">
> Why aren't they also just UInt64 and UInt32, resp.?<br class="">
<br class="">
</span>Let me flip the question: why would they be UInt64 and UInt32? Absent a reason to prefer a specific fixed-with type, Swift integers should generally default to being [U]Int (and ideally Int, but RawExponent is Unsigned).<br class="">
<br class="">
– Steve</blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>