public class test
{
public static void main(String args[])
{
System.out.println(598.42 * 50.0);
}
}
This yields 29920.999999999996 while the actual result should have been 29921. The calculator as well as pen and paper yields the right answer. But the computer doesn't. So does that mean that the computer is incapable of performing calculations to the highest accuracy or am I missing something here.
> So does that mean that the computer is incapable of performing calculations to the
> highest accuracy
Yes. The accuracy (in the sense of precision) required here is infinite and computers aren't capable of that. The problem lies with the infinite amount of memory required to represent numbers infinitely precisely.
The ability of pen and paper to get the "exact" answer is, therefore quite interesting. In effect you apply the procedure you would have learnt at school to which your brain applies some extra reasoning - along the lines of "the factors have 3 decimal places between them so all the infinite decimal places in the product from 4 onwards will be zero".
Could a computer have done this? Certainly: provided you tell it to. For instance you could write a class that represents a decimal number as an int and the position of the dot. You can multiply such numbers with integer multiplication combined with adding the dot position. Such an arrangement won't "work" for decimal multiplication in general - for one thing not all decimal numbers can be represented this way - but it will work for the example you gave and others like it (that contain a finite and rather modest number of nonzero digits).
The fact that the calculator gives the "right" answer is due to the fact that it ... cheats! These things typically use a fairly basic form of rounding that is, if anything, less sophisticated than Java's. What they also do - which is a bit sneaky - is never tell you about the last digit. That way it appears more precise in those simple cases where the human operator already knew the answer. It will still go "wrong" in more complex cases like log(1.1) + log(1.2) + ... + log(2) but most people won't detect the cumulative effect of the calulators primitive rounding.
Java could have employed the same deception. In other words it could have kept all but the first 15 significant figures to itself and truncated the answer after every operation. What you would have seen then would not be29920.999999999996
^
truncate here and roundbut
29921.0000000000and you would have been happy although the answer (and process) would be less accurate.
[Edit]Rereading this, I don't think I was clear that the calculator's trickery consists in having two forms of the number: one that it uses for calculation, the other rounded one for display. There's always going to be some rounding, but at least Java's is precisely specified and easily predictable.
I get what you are trying to say, but the only thing that contravenes is that paper and pen would always yield the most accurate answer if the question in hand yields an integral answer.
The accuracy part would come into effect if we do something like this
598.42 * 49.99999999-> This would yield a solution with a recurring 9 after the decimal point. In this case we would always want the accuracy as 29920.99999999 as we wouldn't want any truncation to take place if the application is looking for a precision upto the tenth place.
But if we look at 598.42 and 50. We see that 42 when multiplied with 5 yields 210 and an extra zero from 50<- would make it 2100. So the accuracy here is lost if the computer shows us recurring 9's i.e. 29920.9999999999 after the period as an alternative for 29921.0, while it should have been 29921.0 in the first place itself if we go by the solution given by the pen and paper, as in 42 * 50 = 2100.
> > *bump*
>
> You should read this:
> http://docs.sun.com/source/806-3568/ncg_goldberg.html
>
> You have been here for a long time, so I'm surprised
> to see that you haven't read it. Read it, do also
> read the javadoc for BigDecimal.
>
> Kaj
Good to hear from you kaj
It looks like I had missed it. Thanks kaj.
Message was edited by:
qUesT_foR_knOwLeDge
> > Off-topic: How are things at the forum? It's been
> a
> > really long time since I visited the forum.
>
> Nothing has changed. People are still posting
> questions before they try to google.
It's nice to hear that our good old forum hasn't changed ;)
> > Off-topic: How are things at the forum? It's
> been a
> > really long time since I visited the forum.
>
> Time is indeed relative. Your posting history
> suggests to me that you've been around here quite
> often.
>
> ~
Those were the rare posts here and there. Couldn't really notice if the forum had changed when I visited the forum then. Need to be at the forum for a longer period to see how are things at the forum. Haven't seen daffy for a long time.
> I get what you are trying to say, but the only thing
> that contravenes is that paper and pen would always
> yield the most accurate answer if the question in
> hand yields an integral answer.
>
> The accuracy part would come into effect if we do
> something like this
>
> 598.42 * 49.99999999-> This would yield a
> solution with a recurring 9 after the decimal point.
> In this case we would always want the accuracy as
> 29920.99999999 as we wouldn't want any truncation to
> take place if the application is looking for a
> precision upto the tenth place.
>
> But if we look at 598.42 and 50. We see that 42 when
> multiplied with 5 yields 210 and an extra zero from
> 50<- would make it 2100. So the accuracy here
> is lost if the computer shows us recurring 9's i.e.
> 29920.9999999999 after the period as an alternative
> for 29921.0, while it should have been 29921.0 in the
> first place itself if we go by the solution given by
> the pen and paper, as in 42 * 50 = 2100.
When you use pen and paper, you're doing it in base 10, with (effectively) infinite base-10 precision.
When Java does it, it's doing it in base-2, with finite base-2 precision.
[url=http://java.sun.com/developer/JDCTechTips/2003/tt0204.html#2]SOME THINGS YOU SHOULD KNOW ABOUT FLOATING-POINT ARITHMETIC[/url]
[url=http://docs.sun.com/source/806-3568/ncg_goldberg.html]What Every Computer Scientist Should Know About Floating-Point Arithmetic[/url]
Another good (slightly simpler) FP explanation:
http://mindprod.com/jgloss/floatingpoint.html
> Those were the rare posts here and there.
Like I said, it's relative. You have multiple posts in 2007 on April 7, April 8, April 9, April 10, April 13, April 17, April 29, May 3, May 12, May 17, and May 19. There are several days in there where you have only one post. If you feel like that's "rare" that's certainly one opinion. To me, it seems pretty regular. It's just an observation.
~
> When you use pen and paper, you're doing it in base
> 10, with (effectively) infinite base-10 precision.
>
> When Java does it, it's doing it in base-2, with
> finite base-2 precision.
>
> [url=http://java.sun.com/developer/JDCTechTips/2003/tt
> 0204.html#2]SOME THINGS YOU SHOULD KNOW ABOUT
> FLOATING-POINT ARITHMETIC[/url]
> [url=http://docs.sun.com/source/806-3568/ncg_goldberg.
> html]What Every Computer Scientist Should Know
> About Floating-Point Arithmetic[/url]
>
> Another good (slightly simpler) FP explanation:
> http://mindprod.com/jgloss/floatingpoint.html
Thanks jeff.
> > Those were the rare posts here and there.
>
> Like I said, it's relative. You have multiple posts
> in 2007 on April 7, April 8, April 9, April 10, April
> 13, April 17, April 29, May 3, May 12, May 17, and
> May 19. There are several days in there where you
> have only one post. If you feel like that's "rare"
> that's certainly one opinion. To me, it seems pretty
> regular. It's just an observation.
>
> ~
Yes. Thats when I just happened to have a few secs off to just visit the forum and make a single post. Just as you have noticed each of those days had just a post each or maybe two which I would term as exceptions as I don't remember spending more than a few minutes at the forum on each of those days.
