> On Nov 1, 2017, at 14:54, Kelvin Ma via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
>> 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).
I can’t imagine it’d ever get far enough for me to care about Swift’s stance on
the issue, but I want to build a 9-“trit” breadboard computer some day, just
for my own edification/amusement.
(FWIW, while I’m not 100% on how the integer protocols ended up, this isn’t the
part that I’d change)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
