<div dir="ltr">I understand.<div>It's just very tempting to try and use the new static computed properties for eg 23 and 52 etc.</div><div>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>/Jens</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:25 AM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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><br></div><div>It sounds like maybe you actually want to be operating directly on bitPatterns, rather than the abstract fields of the types.</div><div><br></div><div>– Steve</div><div><div class="h5"><br><div><blockquote type="cite"><div>On Aug 26, 2016, at 7:21 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:</div><br><div><div dir="ltr">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><br></div><div>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><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <span dir="ltr"><<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Reason for asking is that I have this:<div><br><div><div>extension Double {</div><div> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {</div><div> let bitPattern = s | (1023 << 52)</div><div> self = unsafeBitCast(bitPattern, to: Double.self) - 1.0</div><div> }</div><div>}</div><div>extension Float {</div><div> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {</div><div> let bitPattern = s | (127 << 23)</div><div> self = unsafeBitCast(bitPattern, to: Float.self) - 1.0</div><div> }</div><div>}</div></div><div><br></div><div>But they would be better as:</div><div>extension BinaryFloatingPoint {</div><div> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {</div><div> ... problems here, have to try casting things into RawSignificand's type ...</div><div> }</div><div>}</div><div><br></div></div><div>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><font color="#888888"><div><br></div><div>/Jens</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
><br>
> I can understand why<br>
> Double.RawSignificand is UInt64<br>
> and<br>
> Float.RawSignificand is UInt32<br>
><br>
> But I can't understand why both<br>
> Double.RawExponent<br>
> and<br>
> Float.RawExponent<br>
> should be UInt.<br>
><br>
> Why aren't they also just UInt64 and UInt32, resp.?<br>
<br>
</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>
<br>
– Steve</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>