Groups > comp.lang.java.programmer > #26515

Re: Possible loss of precision

From	Martin Gregorie <martin@address-in-sig.invalid>
Newsgroups	comp.lang.java.programmer
Subject	Re: Possible loss of precision
Date	2013-11-15 21:36 +0000
Organization	A noiseless patient Spider
Message-ID	<l66447$qat$1@dont-email.me> (permalink)
References	<loss-20131113231933@ram.dialup.fu-berlin.de> <87txfe22o1.fsf@golem.phantasia.org> <kkla89tv4vb3c60ao7qkj2hr3kd0ims4gc@4ax.com> <l63mh7$afg$1@dont-email.me> <l63sqt$9bm$1@dont-email.me>

Show all headers | View raw

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       |

Thread

Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-14 20:39 +0100
  Re: Possible loss of precision Gene Wirchenko <genew@telus.net> - 2013-11-14 15:03 -0800
    Re: Possible loss of precision Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-11-14 18:31 -0500
      Re: Possible loss of precision Joerg Meier <joergmmeier@arcor.de> - 2013-11-15 00:55 +0100
      Re: Possible loss of precision Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-11-14 20:19 -0500
        Re: Possible loss of precision taqmcg@gmail.com - 2013-11-15 07:01 -0800
        Re: Possible loss of precision Martin Gregorie <martin@address-in-sig.invalid> - 2013-11-15 21:36 +0000
    Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-15 19:24 +0100
      Re: Possible loss of precision Patricia Shanahan <pats@acm.org> - 2013-11-15 20:48 -0800
        Re: Possible loss of precision Michael Jung <miju@golem.phantasia.org> - 2013-11-17 13:28 +0100
          Re: Possible loss of precision Patricia Shanahan <pats@acm.org> - 2013-11-17 08:05 -0800

csiph-web