On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:
> On Wed, Nov 1, 2017 at 07:24 Daryle Walker <dary...@mac.com> wrote: > >> >> >> Sent from my iPad >> >> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> Right, these issues were discussed when the proposal was introduced and >> reviewed three times. In brief, what was once proposed as `Integer` was >> renamed `BinaryInteger` to avoid confusion in name between `Integer` and >> `Int`. It was also found to better reflect the semantics of the protocol, >> as certain functions treated the value not merely as an integer but >> operated specifically on its binary representation (for instance, the >> bitwise operators). >> >> Do not confuse integers from their representation. Integers have no >> intrinsic radix and all integers have a binary representation. This is >> distinct from floating-point protocols, because many real values >> representable exactly as a decimal floating-point value cannot be >> represented exactly as a binary floating-point value. >> >> >> Abstractly, integers have representations in nearly all real radixes. But >> mandating base-2 properties for a numeric type that uses something else >> (ternary, negadecimal, non-radix, etc.) in its storage is definitely >> non-trivial. Hence the request for intermediate protocols that peel off the >> binary requirements. >> > > Not only binary properties, but specifically two’s-complement binary > properties. You are correct that some operations require thought for > implementation if your type uses ternary storage, or for any type that does > not specifically use two’s-complement representation internally, but having > actually implemented them I can assure you it is not difficult to do > correctly without even a CS degree. > > Again, one must distinguish between the actual representation in storage > and semantics, which is what Swift protocols guarantee. The protocols are > totally agnostic to the internal storage representation. The trade-off for > supporting ternary _semantics_ is an additional set of protocols which > complicates understanding and use in generic algorithms. I am not aware of > tritwise operations being sufficiently in demand. > Before everyone gets carried away with these protocols, can I ask what the real use case for ternary integers is? Also I’m not a fan of bikeshedding protocols for things that don’t exist (yet).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution