Email list hosting service & mailing list manager


Re: meta-comment on typing Per Bothner 16 Oct 2005 20:17 UTC

Your argument hinges on the term "addition", which you don't define,
so it's meaningless.

Do you consider "complex number addition" to be "addition"?
Do you consider "matrix addition" to be "addition"?
If you allow either of the former to be 'addition" then
there is no a priori reason to reject "32-bit unsigned modulo
addition with wrap-around" to be addition as well.

In fact most programming languages do consider the latter to
be "addition".

What it really boils down to:
* Is it wise/useful/desirable to overload operations so
that different (but in-some-way-related) operations are named
by the same operation name?
* Is it wise/useful/desirable overload the operation names for
standard arithmetic to objects that don't obey all the rules
of complex number arithmetic?
* A slightly different question: what is a number?  Is a quantity
with a dimension a number?  Is a 32-bit unsigned machine integer
a number?  Is a complex a number?

I have no problem with you saying that you don't think my idea
is a good idea.  (I'm not sure it is myself - probably not for R6RS.)
But I don't think you have basis for calling t "dead wrong".

bear wrote:
>
> On Thu, 6 Oct 2005, Per Bothner wrote:
>
>
>>As I wrote: I'm *assuming* that + when operating on fixnums
>>will return a fixnum even if it "overflows".
>>
>>I.e. that arithmetic on fixnums are defined "modularly" and
>>fixnums are *not* just a subset of the integers.
>>
>>This implies that (fixnum? 0) is not true, though of course 0
>>can be trivially *converted* to a fixnum: (fixnum? (as <fixnum> 0))
>>is true.
>>
>>I can see that this might be a bit too radical.
>
>
> Um, I would have said "dead wrong" rather than "too radical."
>
> Addition should add.  It should give the correct answer, or
> possibly signal an error.  Answers which are not correct
> answers to addition are *NOT* answers that can or should be
> returned from addition. And some kind of type polymorphism
> with a distinct number type should not cause addition to
> behave differently in the sense of giving answers with
> different numeric values.
>
> If you're talking about some kind of operation that acts
> like addition over a limited range but is restricted to
> that range and has well-defined modular-math semantics
> that happen to be very easy to implement on twos-complement
> machines with 32-bit words, that's valid too, and useful
> in some binary stuff like cryptography, but it is *NOT*
> addition and should not be confused with addition. It is
> its own separate function with different semantics and
> deserves a different function name.
>
> 			Bear
>

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/