On Mon, Feb 19, 2018 at 11:35 PM, bartc <b...@freeuk.com> wrote:
> Sometimes, the reason for creating a special numerical type is precisely so
> you can't do arithmetic on them, if it's not meaningful for the type.
> So the special type of the values 65..90 might not allow the type be
> multiplied or divided, or added to itself. Because they represent characters
> A..Z. Or house numbers. Or the age of pensioners. (You'd need to convert to
> ordinary integers, is that is allowed.)

If they represent characters, then they're not integers. They're
characters. Characters are not integers.

House numbers and pensioners' ages are not unitless numbers. If you
truly want to represent these as actual types, then you need to
incorporate the unit in the type, or have a generic "number and unit"
data type. That would then change the operations permitted on that

None of this says anything about the original question, which was
about numbers. Actual, plain, ordinary integers.

>>  there's no
>> requirement for the result of an operation to have the same type as
>> its inputs:
>>>>> 5 / 2 # two integers
>> 2.5
> Try that when the type of {1..13} represents playing card ordinal values.

And now you're pretending that an enumeration is the same thing as an
integer. You're arguing about a type system, then trying to claim that
everything that can be represented as an integer must be an integer.
Your position is illogical.

> But Python has classes and can do some of this stuff; how would it handle a
> numeric type that is constrained to be whole numbers within 0..9 inclusive?

Do you mean that arithmetic results have to also be constrained, or
that the numeric type must itself only be those few? You could fairly
easily define a data type like this:

Int[0:10] # integer 0...9 inclusive (0..10 inc/exc)
Int[0:10] + Int[0:10] ==> Int[0:19]
Int[0:10] * Int[0:10] ==> Int[0:81]
Int[0:10] / Int[1:10] ==> Fraction

Perfectly sane and useful.


Reply via email to