Prev: Possible easy diagnostic outputting from multiple threads tothe one text frame
Next: JDK 1.6.0_21 released
From: Lew on 8 Jul 2010 13:52 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. > Eric Sosman wrote: > (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). > Once again, as computer people we should all be familiar with the information in <http://docs.sun.com/source/806-3568/ncg_goldberg.html> -- Lew
From: Martin Gregorie on 8 Jul 2010 15:22 On Thu, 08 Jul 2010 14:20:10 +0100, Tom Anderson wrote: > 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! > .....which is why exchange rate calculations for SWIFT and the Euro, to name but two, are spelt out in considerable detail and correct implementation of them is part of the certification tests required for connection to the relevant networks. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Jim Janney on 8 Jul 2010 18:18 "Boris Punk" <khgfhf(a)hmjggg.com> writes: > long l = 9999999999999L; > double f = 0.11111111111D; > double fl = f+l; > System.out.println(fl); > > =9.999999999999111E12 > > > Where's the rest of the 0.1111111's ? The short and grossly oversimplified answer is that there are an infinite number of real numbers and we can't possibly represent them all with any finite alphabet. Floating point is a notation that allows us to represent a subset of the real numbers, a subset that in practice often contains values that are "close enough", where "close enough" depends heavily on the problem at hand. Unfortunately this subset is not closed under arithmetic: many simple operations can generate values outside of the subset that can be represented. A good implementation of floating point arithmetic will always give you the representable value closest to the actual result: in practice you can't always count even on this, although it shouldn't be too far off. For the long answer I recommend taking a class on axiomatic set theory (one of the best math classes I ever took). Rational numbers are significantly different from integers, and real numbers are truly weird. -- Jim Janney
From: Jim Janney on 8 Jul 2010 18:18 Tom Anderson <twic(a)urchin.earth.li> writes: > 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! Financial calculations, especially ones involving interest rates, often use values that are expressed as decimal fractions, 0.01, 0.03, etc. These can be represented exactly in fixed or floating decimal, but usually not in binary. 0.125 can, but it's an exception. Every so often I have a go at trying to explain this to my coworkers, so far without much success. -- Jim Janney
From: Jim Janney on 8 Jul 2010 19:05
Lew <noone(a)lewscanon.com> writes: > Boris Punk wrote: >> I did plenty of manual sums of floating point numbers at college on paper - >> just wanted a refresher from some knowlegeable folk on how it's applied in >> java [sic]. Is Lew on a period or something? Hehe get it...period...never mind.... > > Are you suggesting that there's something wrong with programmers > knowing the basics of our profession? Or with espousing that we do? > > Seems to me that someone with a commitment to excellence in the > programming profession would agree that we should improve our skills, > study the basics, and strive for superiority in our professionalism, > rather than make sexist, low-brow remarks about someone who makes > those points. I'm with Lew on this one: it's an important subject and I meet too many programmers, many with CS degrees, who not only don't understand it but don't even seem to know that it exists. I learned enough numerical analysis to understand how little I know about it: many programmers don't seem to know even that. -- Jim Janney |