[swift-evolution] protocol-oriented integers (take 2)

[Xiaodi Wu]

On Sun, Jan 29, 2017 at 2:30 PM, David Sweeris <davesweeris at mac.com> wrote:

>
> On Jan 29, 2017, at 12:13, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris <davesweeris at mac.com>
> wrote:
>
>>
>> On Jan 29, 2017, at 10:36, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> 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?
>>
>>>
>> 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<Int8,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.
>>
>> In terms of justification, I think probably all I can offer is that I
>> *think* 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.
>>
>
> 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.
>
>
> 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.
>

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!


> 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.
>

`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.


>
> - Dave Sweeris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170129/bf3d8b58/attachment.html>