On 3/18/16 21:00, Dany St-Amant via swift-evolution wrote: > >> Le 18 mars 2016 à 18:42, Rainer Brockerhoff via swift-evolution >> <[email protected]> a écrit : >> >> First draft towards a tentative pre-proposal: >> https://gist.github.com/rbrockerhoff/6874a5698bb479886e83 >> ------ >> >> I propose, therefore, an internal data layout like this: >> >> UInt16 - position of the “virtual” point, starting at 0 >> UInt16 - data array size - 1 >> [Int32] - contiguous data array, little-endian order, grown as needed. >> Note that both UInt16 fields being zero implies that the number is >> reduced to a 32-bit Integer. Number literals in Swift can be up to 2048 >> bits in size, so the maximum data array size would be 64, although it >> could conceivably grow beyond that. The usual cases of the virtual point >> position being 0 or 2 could be aggressively optimized for normal >> arithmetic operators. > > By using a table of signed Int32, I think you'll lose one bit every time the > number is extended. > Should the sign of the number be hidden in the data array size, either as the > sign or as the lsb? > - second field = (data array size - 1) << 1 | (negative ? 1 : 0)
Hm. I didn't really mean that the sign should be repeated in every element, so technically it should be [UInt32] with a note saying negative numbers are stored in 2's complement. -- Rainer Brockerhoff <[email protected]> Belo Horizonte, Brazil "In the affairs of others even fools are wise In their own business even sages err." http://brockerhoff.net/blog/ _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
