Arithmetic
in [Java Programming]
|
Prev: Possible easy diagnostic outputting from multiple threads tothe one text frame
Next: JDK 1.6.0_21 released
From: Martin Gregorie on 8 Jul 2010 08:04 On Wed, 07 Jul 2010 19:24:50 -0400, Arne Vajhøj wrote: > On 07-07-2010 14:13, Lew wrote: >> The reason that computer programmers command such good wages is that it >> is a *skilled* profession. Most people cannot do it, and of those who >> can it requires intelligence, study and practice, i.e., it requires >> tremendous intellectual effort and capacity. > > Why can I hear violins in the background? > > :-) > >> It is one of the most fundamental and introductory aspects of computer >> programming that floating-point "numbers" in a computer are limited- >> precision approximations of real numbers. > > There are actually programmers that are never exposed to floating point. > .... but there are integer-only programmers who never 'get' computer arithmetic. I once worked with a COBOL 'programmer' who never understood why divide by zero would trigger an ON SIZE ERROR clause or crash the program if the DIVIDE sentence didn't contain ON SIZE ERROR. Various people tried to explain it to him / pound it into his head but he was totally resistant to the concept. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Martin Gregorie on 8 Jul 2010 09:06 On Wed, 07 Jul 2010 21:32:30 -0400, Lew wrote: > Lew wrote: >>> It is one of the most fundamental and introductory aspects of computer >>> programming that floating-point "numbers" in a computer are limited- >>> precision approximations of real numbers. > > Arne Vajhøj wrote: >> There are actually programmers that are never exposed to floating >> point. > > Then a) they aren't programmers and b) they are derelict if they wish to > be. > Depends what they're doing, e.g. if they're writing financial software in COBOL or RPG 3, its quite likely that they may never need use floating point in their entire working life: by default COBOL does fixed decimal point arithmetic which is more appropriate for financial calculations than floating point because the answer is always exact. You'll find that central banks and international networks such as SWIFT have mandatory rules for currency conversion that specify the required precision and how rounding and or remainders are to be handled. However, COBOL introduces its own arithmetic oddities because its really using integer arithmetic with an implied decimal point. For example, the correct answer to dividing 0.4 by 2.0 using PIC S9(6)v9(6) variables is a result of 0.0 with a remainder of 0.4 because its actually dividing 400000 by 2000000. This is spelt out in the COBOL specification - and is, of course, exactly how BigDecimal handles division if you use the divideAndRemainder() method. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Tom Anderson on 8 Jul 2010 09:20 On Thu, 8 Jul 2010, Martin Gregorie wrote: > On Wed, 07 Jul 2010 21:32:30 -0400, Lew wrote: > >> Lew wrote: >>>> It is one of the most fundamental and introductory aspects of computer >>>> programming that floating-point "numbers" in a computer are limited- >>>> precision approximations of real numbers. >> >> Arne Vajh?j wrote: >>> There are actually programmers that are never exposed to floating >>> point. >> >> Then a) they aren't programmers and b) they are derelict if they wish to >> be. > > Depends what they're doing, e.g. if they're writing financial software in > COBOL or RPG 3, its quite likely that they may never need use floating > point in their entire working life: by default COBOL does fixed decimal > point arithmetic which is more appropriate for financial calculations > than floating point because the answer is always exact. Exact, although not necessarily correct! tom -- Once you notice that something doesn't seem to have all the necessary parts to enable its functions, it is going to mildly bug you until you figure it out. -- John Rowland
From: Chase Preuninger on 8 Jul 2010 11:12 They exist still in memory. Then you call System.out.println(f1) it is really like calling System.out.println(String.valueOf(f1)) the valueOf() function is creating its own representation of the number. Try using some of the number format classes in the java.text package.
From: Eric Sosman on 8 Jul 2010 13:45
On 7/8/2010 11:12 AM, Chase Preuninger wrote: > They exist still in memory. Then you call System.out.println(f1) it > is really like calling System.out.println(String.valueOf(f1)) the > valueOf() function is creating its own representation of the number. > Try using some of the number format classes in the java.text package. (Somewhere in the context lost to overzealous snippage, Chase is answering "Where's the rest of the 0.1111111's?" from an O.P. who printed the result of `9999999999999L + 0.11111111111D'.) The missing low-order digits do *not* "exist still in memory," as others have explained. A Java `double' has 53 bits' worth of precision, just a little less than 16 decimal digits. The O.P.'s 24 decimal digits are far too many for `double', and the lost bits exist nowhere (except in fevered imaginations). -- Eric Sosman esosman(a)ieee-dot-org.invalid |