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 11:12:27 -0400
Organization: e1
Lines: 48
Message-ID: <j0k14r$7rr$1@speranza.aioe.org>
References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.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> <j0j5ie$v55$1@speranza.aioe.org> <slrnj2qjgv.6gl.avl@gamma.logic.tuwien.ac.at>
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:6536

On 25/07/2011 7:06 AM, Andreas Leitgeb wrote:
> Henderson<h1@g1.f1>  wrote:
>>> 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. ;)
>
> It's quite likely that the reviewer who inevitably will shoot the
> programmer for this, will have the jury's sympathy and not be
> punished...  ;)
>
> A more fundamental problem with operator overloading for "Arithmetic"
> types is, when Arithmetic types can or cannot be mixed for a particular
> operation.
>
> Simple example:  what would be the sum of
> BigInteger("123456789012345678901234567890123456789012") and some
> Complex( 0.0 , Math.PI )?

Ideally, it would be a Complex with bignum components, preserving precision.

This seems to require Complex<BaseType> rather than just Complex.

Of course you also raise a valid point regarding overloading for 
conversions. Probably you'd have to create a whole framework, with a 
NVector<T> for "things with dimension > 1 over the real numbers" and 
NVector<BigDecimal> of appropriate dimensionality as the conversion 
intermediary (so as not to lose either precision or dimensions in going 
to the intermediary) -- just BigDecimal when one-dimensional. Then 
conversion to and from BigDecimal and NVector<BigDecimal> is all that is 
required.

Until some enterprising mathematician thinks up something that can be 
added and multiplied, but has no sensible correspondence to any subset 
of any kind of vectors of real numbers ...

I think you can cram matrices in there, and complex numbers. Numbers mod 
something, too -- though do you quietly truncate when converting to 
these, or throw an exception? Of course, primitive int is already 
actually an integers-mod-2^32 type so that may be considered already 
settled.

A quick search of wikipedia for "numbers" and looking at terms in the 
results that seem to describe funny kinds of numbers turns up "p-adic 
numbers" and "hyperreal numbers" that I'm guessing would still run into 
problems here. No operator overloading for those, then. :)