<div dir="ltr">Oh, I just saw that SE-0104 was accepted for Swift 3: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022977.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022977.html</a><div><br></div><div>Sorry for the noise, I will try to check basic things like this up before asking here next time.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 10:20 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">Btw, I had a look quick at the development snapshot 08-25-a toolchain and it seems like it has SE-0104 partly implemented.<div><br></div><div>(For example Double doesn't conform to SignedArithmetic while it does conform to Arithmetic. And the Integer types doesn't conform to Arithmetic)</div><div><br></div><div>Is SE-0104 not part of Swift 3, and will thus not be included in Xcode 8 GM?</div><span class="HOEnZb"><font color="#888888"><div><br><div>/Jens</div><div><div><br></div><div><br></div></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 2:31 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">Ok, I've learned a lot, thanks!<span><font color="#888888"><div>/Jens</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 2:26 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>For any given concrete type, it’s pretty straightforward to map [0, .max] to [0,1) — note that this is a bit different from what you seem to have been doing originally, mapping e.g. [0, 2**52) to [0, 1):</div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">init</span><span>(unitRange s: </span><span style="color:#c35900">UInt64</span><span>) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">self</span><span> = </span><span style="color:#c35900">Self</span><span>(s >> </span><span style="color:#c35900">UInt64</span><span>(</span><span style="color:#36568a">63</span><span> - </span><span style="color:#c35900">Self</span><span>.</span><span style="color:#587ea8">significandBitCount</span><span>)) * .</span><span style="color:#587ea8">ulpOfOne</span><span>/</span><span style="color:#36568a">2</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> }</span></div></div><div><br></div>Making this generic over integer types is painful without the SE-0104 integer protocols, however.<div><br></div><div>– Steve<div><div><br><div><br><div><blockquote type="cite"><div>On Aug 26, 2016, at 8:13 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:</div><br><div><div dir="ltr">Ah, right! Thanks again.<div>How would you make all integer type (UIntN, IntN) convertible/mappable from their respective [.min, .max] range to Double/Float unit range [0, 1)?</div><div>/Jens</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 2:06 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>Note that with the bug fixed, the result will still not be 1.nextDown, because the size of an ulp changes at 1; the values you produce will be space .ulpOfOne apart, but 1.nextDown is 1 - ulpOfOne/2.</div><div><br></div><div>– Steve</div><div><div><br><div><blockquote type="cite"><div>On Aug 26, 2016, at 8:00 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:</div><br><div><div dir="ltr">Thanks, but there seem to be something not working the same as in my original code, here is a quick test of your code:<div><br><div><div>protocol BinaryFloatingPointWithBitPatt<wbr>ern: BinaryFloatingPoint {</div><div> init(bitPattern: RawSignificand)</div><div> var bitPattern: RawSignificand { get }</div><div>}</div><div><br></div><div>extension Float: BinaryFloatingPointWithBitPatt<wbr>ern { }</div><div>extension Double: BinaryFloatingPointWithBitPatt<wbr>ern { }</div><div><br></div><div>extension BinaryFloatingPointWithBitPatt<wbr>ern {</div><div> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {</div><div> self = Self(bitPattern: Self(1).bitPattern | s) - 1</div><div> }</div><div>}</div><div><br></div><div>typealias T = Double</div><div>// typealias T = Float</div><div><br></div><div>let allSignificantBitsSet = T.RawSignificand((1 << T.significandBitCount) - 1)</div><div>print("bits set in signigicant:", String(allSignificantBitsSet, radix: 2).characters.count) // 52</div><div>let a = T.init(bitPattern: 0)</div><div>let b = T.init(bitPattern: allSignificantBitsSet)</div><div>print(a) // 0.0, correct.</div><div>print(b) // 2.2250738585072e-308. Wrong, this should be (1.0).nextDown.</div></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:57 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"><span><div>If BinaryFloatingPoint had init(_: RawSignificand), you could also just write:</div><div><span style="font-family:Menlo;font-size:11px;color:rgb(54,86,138)"><br></span></div><div><span style="font-family:Menlo;font-size:11px;color:rgb(54,86,138)">extension</span><span style="font-family:Menlo;font-size:11px"> </span><span style="color:rgb(195,89,0);font-family:Menlo;font-size:11px">BinaryFloatingPoint</span><span style="font-family:Menlo;font-size:11px"> {</span></div></span><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">init</span><span>(unitRangeFromRawSignifica<wbr>nd s: </span><span style="color:#c35900">RawSignificand</span><span>) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">self</span><span> = </span><span style="color:#c35900">Self</span><span>(s) * .</span><span style="color:#587ea8">ulpOfOne</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> }</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span>}</span></div></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><br></div><div style="margin:0px;line-height:normal">(this is why I ask if RawSignificand is really the type you want; if you use some concrete integer type this will work). But once we have all the new integer protocol conformances, we’ll have a generic init from any integer type (this was already reviewed for FloatingPoint, but isn’t implementable without the Integer support), which will also make this possible.</div><div><div><br><div><blockquote type="cite"><div>On Aug 26, 2016, at 7:47 PM, Stephen Canon via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">Assuming RawSignificand really is the type you want, I think this does what you’re looking for?<br><br><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="color:#36568a">protocol</span><span> BinaryFloatingPointWithBitPatt<wbr>ern: </span><span style="color:#c35900">BinaryFloatingPoint</span><span> {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">init</span><span>(bitPattern: RawSignificand)</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">var</span><span> bitPattern: RawSignificand { </span><span style="color:#36568a">get</span><span> }</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span>}</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><span></span><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(195,89,0)"><span style="color:rgb(54,86,138)">extension</span><span> </span><span>Float</span><span>: </span><span>BinaryFloatin<wbr>gPointWithBitPattern</span><span> { }</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(195,89,0)"><span style="color:rgb(54,86,138)">extension</span><span> </span><span>Double</span><span>: </span><span>BinaryFloati<wbr>ngPointWithBitPattern</span><span> { }</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(195,89,0)"><span><br></span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(195,89,0)"><span style="color:#36568a">extension</span><span> </span><span>BinaryFloatingPointWithBitPatt<wbr>ern</span><span> {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">init</span><span>(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> </span><span style="color:#36568a">self</span><span> = </span><span style="color:#c35900">Self</span><span>(bitPattern: </span><span style="color:#c35900">Self</span><span>(</span><span style="color:#36568a">1</span><span>).</span><span style="color:#587ea8">bitPattern</span><span> </span><span style="color:#587ea8">|</span><span> s) </span><span style="color:#587ea8">-</span><span> </span><span style="color:#36568a">1</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span> }</span></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span>}</span></div><br><blockquote type="cite">On Aug 26, 2016, at 7:38 PM, Stephen Canon via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br><br>Where does your RawSignificand input come from? Is that really the type that you want?<br><br>I don’t think you really need very much boilerplate at all here.<br><br><blockquote type="cite">On Aug 26, 2016, at 7:30 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:<br><br>I understand.<br>It's just very tempting to try and use the new static computed properties for eg 23 and 52 etc.<br>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).<br>/Jens<br><br>On Sat, Aug 27, 2016 at 1:25 AM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote<wbr>:<br>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.<br><br>It sounds like maybe you actually want to be operating directly on bitPatterns, rather than the abstract fields of the types.<br><br>– Steve<br><br><blockquote type="cite">On Aug 26, 2016, at 7:21 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:<br><br>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.<br><br>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).<br><br>/Jens<br><br><br>On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wr<wbr>ote:<br>Reason for asking is that I have this:<br><br>extension Double {<br> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {<br> let bitPattern = s | (1023 << 52)<br> self = unsafeBitCast(bitPattern, to: Double.self) - 1.0<br> }<br>}<br>extension Float {<br> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {<br> let bitPattern = s | (127 << 23)<br> self = unsafeBitCast(bitPattern, to: Float.self) - 1.0<br> }<br>}<br><br>But they would be better as:<br>extension BinaryFloatingPoint {<br> init(unitRangeFromRawSignifica<wbr>nd s: RawSignificand) {<br> ... problems here, have to try casting things into RawSignificand's type ...<br> }<br>}<br><br>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.)<br><br>/Jens<br><br><br>On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote<wbr>:<br>> 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>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<br><br><br></blockquote><br><br></blockquote><br>______________________________<wbr>_________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-dev</a><br></blockquote><br></div>______________________________<wbr>_________________<br>swift-dev mailing list<br><a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-dev" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-dev</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>