Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Possible loss of precision Date: Fri, 15 Nov 2013 21:36:07 +0000 (UTC) Organization: A noiseless patient Spider Lines: 39 Message-ID: References: <87txfe22o1.fsf@golem.phantasia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 15 Nov 2013 21:36:07 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="26973"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/79RbC2JYAXHz1Rs26ih7hv2hawAGfTto=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:v1zlkxJ5N9y01xV5DYbuGqbPvtI= Xref: csiph.com comp.lang.java.programmer:26515 On Thu, 14 Nov 2013 20:19:27 -0500, Eric Sosman wrote: > Neither the numerator nor the denominator can be represented exactly as > stated, yet the quotient is (probably; cook up your own numbers if mine > are faulty) exactly 2.0. Would it be a good idea to let this construct > slide through unremarked? Or should javac acknowledge the inherent > imprecisions in the operations leading to the exactly-integral result? > I think Java is weak in this area - the ancient Algol68 language did this better with its explicit concept of widening and narrowing numbers int n; float f; double d; d = f; d = n; f = n; are all examples of widening, and all are legal as you'd expect because there is no loss of precision, while n = f; n = d; f = d; are all examples of narrowing, which involves loss of precision, and so are rejected by the compiler, which forces you to use a conversion function, such as round(), floor() or ceil(). Compared with this, using a cast to narrow a number is a very blunt instrument. The standard A68 library overloaded these functions so they worked correctly between all numeric types including, IIRC, that you could use them to convert and numeric type to or from a bool. The odd thing is that all Java need to fix this is to extend the Math class with the appropriate methods. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |