Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Henderson <h1@g1.f1>
Newsgroups: comp.lang.java.programmer
Subject: Re: Arithmetic overflow checking
Date: Mon, 25 Jul 2011 03:21:46 -0400
Organization: e1
Lines: 84
Message-ID: <j0j5ie$v55$1@speranza.aioe.org>
References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <b3d4a08b-3428-442a-8cce-30edc2868a47@5g2000yqb.googlegroups.com> <09fe171s46ilvq9qmn254dctunm6noh0ps@4ax.com> <f6ed8d08-bc7a-43e4-aecf-878511705353@j15g2000yqf.googlegroups.com> <4e262731$0$314$14726298@news.sunsite.dk> <j059o8$684$1@dont-email.me> <4e26300b$0$309$14726298@news.sunsite.dk> <cdyVp.5929$Vn5.2217@newsfe18.iad> <4e26b4ed$0$2501$db0fefd9@news.zen.co.uk> <f126e0ad-e1e5-47c8-949e-e38b3598d5ff@m5g2000prh.googlegroups.com> <4e28097f$0$2533$da0feed9@news.zen.co.uk> <f9939820-502d-4973-b008-0b62536ab967@m3g2000pre.googlegroups.com> <slrnj2ghv0.6gl.avl@gamma.logic.tuwien.ac.at> <7a23c9d2-508f-4dbd-af91-8cdf2a9764e1@p29g2000pre.googlegroups.com> <j09t06$4bo$1@dont-email.me> <slrnj2jc3u.6gl.avl@gamma.logic.tuwien.ac.at> <IMBWp.68441$5v5.52239@newsfe11.iad> <slrnj2mdoi.6gl.avl@gamma.logic.tuwien.ac.at> <j0g1i4$nus$1@speranza.aioe.org> <ueidnUcxuMPT2LHTnZ2dnUVZ_uKdnZ2d@earthlink.com>
NNTP-Posting-Host: cJ+uP0NdDAbt8UCZbZVtiQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: WinVN 0.99.12z (x86 32bit)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6524

On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
> On 7/23/2011 7:55 PM, Henderson wrote:
>> We could go further and rewrite Number.java so that it is Number<T
>> extends Number<T>> and defines:
>
> I don't think it would be wise to tie operator overloading to Number.
> Number defines a series of conversions that make some sense for those
> types that represent subsets of the real line.

I wasn't thinking beyond the real line to the more abstract stuff 
mathematicians futz around with and consider to have addition and 
multiplication.

But short of giving general operator overloading to the masses (which 
the gurus in charge of Java clearly do not want to do), there *is* a 
way: introduce an abstract superclass, say, AbstractNumber or 
ArithmeticComposable or something for "things that aren't necessarily 
normal numbers, but have the basic arithmetic operations".

> I think it might be better to create a marker interface
> java.math.Arithmetic.

That sneaks in arbitrary operator overloading through the back door, as 
people slap "implements java.math.Arithmetic" on 
"JFoobarSQLQueryEnumerator" and implement ".plus" for it. ;)

Even as things go, I'd like there to be some compiler magic making the 
ArithmeticComposables (or whatever) have automatically final fields, 
anything with that as an ancestor, as well. It should be that a += b 
changes what math object the reference a points to, but doesn't change a 
for anybody else, so all the arithmetic operations should return new 
objects (as currently seems to be the case for BigInteger and 
BigDecimal), not mutate the original.

> I do like the idea of a fixed mapping from
> operators to method names that are normal identifiers.

It's also the only way to do it without adding new keywords and syntax 
in a probably source-compatibility-breaking way. And do we really want 
C++'s "operator+" notation?

> I don't think
> all arithmetic types should be required to support all operations. For
> example, consider negate and an unsigned type, or reciprocal and an
> integer type.

There's two approaches to dealing with that.

1. AbstractNumber implements everything, but they all throw
    UnsupportedOperationException. You override what you can support.

2. AbstractNumber doesn't even specify some of these, but +, -, etc.
    may expand into them anyway, and the compiler will then complain
    if the corresponding named method is not found.

One problem with this, though, is that implementing a - b when a is 
primitive and b isn't, and likewise a / b, seems to require having 
negate and reciprocal, respectively, supported by whatever the return 
type of b - a and b / a would be.

There's also a possible precision problem with a/b being computed as 
1/(b/a) in these cases.

As an alternative, perhaps boxing transformations can be expected 
instead: valueOf(int), etc. methods will be used so if b is of an 
ArithmeticComposable type Foo with a valueOf(int) method and a is an 
int, or can be widened to int (short, byte), then a + b becomes 
Foo.valueOf(a).plus(b).

Of course, valueOf may need to cope with values out of range. What if 
Foo is your hypothetical unsigned type and a is -42? RuntimeExceptions 
seem indicated in these cases. We already have an ArithmeticException 
class, currently used for BigInteger/BigDecimal ops that result in 
division by zero or non-representable values (in the case of a BD with 
unlimited precision -- another spot where we could sorely use a Rational 
class). I'd suggest including an ArithmeticRangeException subclass of 
that for use in such valueOf methods.

And once boxing conversions are being included, why not go ahead and 
allow any ArithmeticComposable with intValue or similarly-named methods 
be autounboxed when used in contexts that expect a primitive? (Though a 
+ b and other arithmetic situations will never unbox b instead of boxing 
a, presuming that the specialized type of b is desired. Manual unboxing 
can be done if the opposite is desired, e.g. a + b.intValue().)