On Sun, Jan 29, 2017 at 2:30 PM, David Sweeris <daveswee...@mac.com> wrote:
> > On Jan 29, 2017, at 12:13, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris <daveswee...@mac.com> > wrote: > >> >> On Jan 29, 2017, at 10:36, Xiaodi Wu <xiaodi...@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution