<div dir="ltr">On Sun, Jan 29, 2017 at 2:30 PM, David Sweeris <span dir="ltr"><<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><div><br></div><div>On Jan 29, 2017, at 12:13, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris <span dir="ltr"><<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_-2529960263240559010gmail-"><div><br></div><div>On Jan 29, 2017, at 10:36, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite">Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, but the performance hit for any useful computation over a large array would probably tilt heavily in favor of plain 64-bit integers. What's your use case for such a 40-bit type? And is it common enough to justify such a facility in the stdlib vs. providing the tools to build it yourself?<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
</blockquote></div>
</blockquote><div><br></div></span>I can think of two use-cases. One — saving memory for large #s of allocations — you already mentioned. The other is for easing interactions with on-disk data. For example, if you're working with some format that has 24-bit ints, you could use "CompoundWhateverItWasCalled<I<wbr>nt8,Int16>". It doesn't make much difference when you're loading the data, but when you're writing it back out, you wouldn't have to worry about trimming that last byte or what to do if the value won't fit in 24 bits. I mean, obviously you'd still have to handle it, but the overflow would happen in the calculation that causes it rather then while you're busy doing something else.<br><div><br></div><div>In terms of justification, I think probably all I can offer is that I <i>think</i> it wouldn't be materially harder or less efficient to implement this than it would be to write a "DoubleWidth<T>" type... It's extra functionality for free, at least in terms of effort. It would increase the API surface, but not by much. Assuming that "DoubleWidth" could just be a typealias, that is. If I'm wrong about it being "that easy", then I don't think it'd be worth it. As you noted, it is somewhat niche.</div></div></blockquote><div><br></div><div>Unless I'm mistaken, DoubleWidth would be implemented using doubleWidthMultiply and doubleWidthDivide facilities provided in these new integer protocols. As the protocol documentation says, DoubleWidth is really intended for wider types, not arbitrarily sized narrower ones. There's no obvious way I can see to implement the same thing for two types of unequal bit width, short of determining dynamically, at each operation, which of your two types has the larger bit width and truncating bits accordingly. So if you want a 24-bit Int, it's unclear to me why you'd choose what's effectively DoubleWidth<Int16> minus 8 bits rather than Int32 minus 8 bits.</div></div></div></div>
</div></blockquote><br></div></div><div>It's a trade-off between computationally efficiency and memory/storage efficiency. If you want your answer sooner, pick Int32, accept that you're "wasting" a byte, and manually trim the value later. If you'd rather have your 24-bit int only actually take up 24 bits or not have to worry about its value taking more than 24 bits, pick the other one.</div></div></blockquote><div><br></div><div>You shouldn't have to make any trade-off: these protocols should make it easy for you to make your own Int24 that is both fast and exactly 24 bits!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I'll have to look at the doubleWidthMultiply/Divide functions later when I get home. Don't know if they'd actually throw a wrench in my crazy scheme, or if it's all just in the name. If this causes any problems for DoubleWidth, I don't think it'd be worth doing this.</div></div></blockquote><div><br></div><div>`doubleWidthMultiply` gives you the high and low halves of the result in a tuple. Unless I'm mistaken, getting the high and low halves are machine instructions. Put them together and you have a double-width value.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div>- Dave Sweeris</div></div></blockquote></div><br></div></div>