Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news-peer.in.tum.de!news.belwue.de!not-for-mail
From: Thomas Richter <thor@math.tu-berlin.de>
Newsgroups: comp.lang.java.programmer
Subject: Re: Arithmetic overflow checking
Date: Tue, 26 Jul 2011 09:43:13 +0200
Organization: InterNetNews at News.BelWue.DE (Stuttgart, Germany)
Lines: 62
Message-ID: <j0lr6i$p6$1@news.belwue.de>
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> <6bmdnfQwfsYovLDTnZ2dnUVZ_qydnZ2d@earthlink.com>
NNTP-Posting-Host: rusime04.rus.uni-stuttgart.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.belwue.de 1311666194 806 129.69.58.55 (26 Jul 2011 07:43:14 GMT)
X-Complaints-To: news@news.belwue.de
NNTP-Posting-Date: Tue, 26 Jul 2011 07:43:14 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110702 Icedove/3.0.11
In-Reply-To: <6bmdnfQwfsYovLDTnZ2dnUVZ_qydnZ2d@earthlink.com>
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6568

Am 25.07.2011 09:56, schrieb Patricia Shanahan:
> On 7/25/2011 12:21 AM, Henderson wrote:
>> 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.
>
> Historically, complex numbers were indeed invented by and for
> mathematicians for the abstract satisfaction of having solutions for all
> quadratic equations.

Not at all! There was simply no need to solve quadratic equations like 
x^2 + 4 = 0 simply because everyone knew, and it was obvious, that this 
equation *does not have* a solution.

Complex numbers were invented as a tool to solve *cubic* equations. The 
tricky thing is that, if you want to solve a cubic equation, you *know* 
that it must either have one, two or three solutions, ever. However, in 
the three-solution case, a closed formula for computing the solutions 
was found, but this equation required you, somewhere in the middle, to 
handle with roots of negative numbers. All these strange negative roots 
then vanish again in the final solution using rules like sqrt(-1) * 
sqrt(-1) = -1, and then cancel out, so everything was "correct" in the 
end. All what happened then is that these rules for manipulating the 
strange temporary = "imaginary" numbers where written down, and *this* 
gave the complex numbers.

Thus, complex numbers weren't an abstract invention by crazy 
mathematicians trying to solve what wasn't possible to solve, but rather 
as a toolkit to solve something very practical, namely to apply an 
algorithm for solving cubic(!) equations. This is very much a useful 
task, as it is to use complex numbers to describe AC currents.

That java lacks operator overloading is a historic decision, probably 
taken on the basis that C++ started with this feature, and everyone 
considered it "so cool" that it was misused for all types of nonsense. 
Basically, I don't consider the choice of the C++ STL to use << and >> 
operators for input and output a sane one, and probably the java 
language designers had the same impression, so wanted to avoid it, but 
then overdid it by disallowing operator overloading in total.

Nowadays, one can probably say that operator overloading *is* a useful 
tool, but as for all useful tools it is one that should be handled with 
care, and a tool that can cause quite some trouble in the hands of 
fools. Thus, what C++ overdid, and Java "under"-did. From today's 
perspective, I *would* prefer to have operator overloading in java, but 
apply it only where it makes sense and the semantics of operators is 
correct. That is, apply it to numeric types (numbers including complex 
numbers, matrices, vectors). Appyling it to I/O as does C++ is, IMHO, 
not a good idea.

Greetings,
	Thomas