Why the excess 0's?

I'm doing my homework and for the life of me, I can't understand why a simple computation is giving me 12 extra 0's? It's a simple program computing the area of a rectangle (area = w * h)

public class Exercise01_08 {
//displays the area of a rectangle where w = 4.5 and h = 7.9
public static void main(String[] args) {
System.out.println(4.5 * 7.9);
}
}

The answer I get is 35.550000000000004

It should be 35.55....what did I do wrong? I get this on Netbeans as well as the Command Prompt..

Thanks for the assistance!

Eddie Gerlach
Greenhorn

Because floating point in computers is imprecise.

Bear,

Thanks for the prompt reply....I read the additional info and my head is swimming....it's making sense....slowly...so, my response it correct, even if it did take the computation took it out to the 12th place...

I thought there were invisible "ghosts" in my code that was making my machine unhappy...

Eddie Gerlach
Greenhorn

Its a common problem. While I love the article that @bear linked to, its really that floating point numbers are precise but their precision is not decimal, and is contrary to human understanding. We have ten fingers and ten toes, so we learn to count by ten. floating point numbers count by 1/2, 1/4, 1/8, 1/16, 1/32 etc. Note particularly that 1/10 and 1/100 are missing from the list.

Pat,

Thank you for the insight....coming over from Trucking (Owner/Operator) and attempting to teach myself Java, it's certainly a lot to digest and I appreciate all the help and support I can get....it sounds like I'm on track, but if I drift a bit, I feel confident everyone here in the Big Moose Saloon will keep me in line....cheers!

Eddie Gerlach
Greenhorn

As a simple and probably somewhat surprising example, take the case that it's impossible to exactly represent one-tenth (decimal 0.1) in a Java double. (Or any other implementation of IEEE 754).

In base-2, 0.1 is one-half, 0.01 is one-fourth, etc. There is no finite sequence in base-2 that adds up to exactly one tenth, just as 1/3 and 1/7 are repeating decimals in base-10 (and could simply be represented by 0.1 in base-3 and base-7, respectively).

Eddie Gerlach wrote:Thank you for the insight....coming over from Trucking (Owner/Operator) and attempting to teach myself Java, it's certainly a lot to digest and I appreciate all the help and support I can get...

Well you can add me to your list. Trucking to Java, eh? Kudos to you.

it sounds like I'm on track, but if I drift a bit, I feel confident everyone here in the Big Moose Saloon will keep me in line....cheers!

And don't worry if it takes a while. Programming is not simple. This is a great article about what you can expect, and also contains some very good tips to help the learning process.

Best of luck.

Winston

Winston,

Thanks a bunch! What an awesome article! I did some brief programming, like 30 years ago in high school learning BASIC, which is procedural, if I remember correctly, but nothing like this...I did research on Java and found it fascinating, plus the wages weren't too shabby, either!

I realize it will take some time to reach a level of competency and professionalism, but have never been more excited about my new career choice! I'll probably be the oldest entry-level programmer in the world, but hey, I can use that to my advantage, too!....cheers!

Eddie Gerlach
Greenhorn

I think there are versions of IEEE754 numbers which do preserve decimal values precisely, but they are not implemented in Java. Note these decimal numbers will not preserve ⅓ etc., and they can only represent ½ ¼ ⅛ etc accurately for a small range of numbers, where the denominator is ≤ 2^n, where n is the number of places after the decimal point.

Of course that is now all wrong, because they have changed IEEE754 and they enganged in mortal combat!

Campbell Ritchie wrote:I think there are versions of IEEE754 numbers which do preserve decimal values precisely, but they are not implemented in Java. Note these decimal numbers will not preserve ⅓ etc., and they can only represent ½ ¼ ⅛ etc accurately for a small range of numbers, where the denominator is ≤ 2^n, where n is the number of places after the decimal point.

Since IEEE 754 is a base-2 representation, any negative powers of 2, or sums of negative powers of 2, can be represented exactly, out to the number of digits available. So 0.5, 0.25, 0.125, etc., along with 0.75, 0.625, and so on, can be represented exactly. Not 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8 or 0.9 though.

Or are you saying that some versions of the spec reserve "special values" for some non-power-of-2 fractions?

[EDIT: Nevermind, just looked. I see that there are also decimal versions of IEEE 754. I never knew that before.]

Campbell,

Nice article....read the link of "they engaged in mortal combat" and it took me to an interesting site, which I bookmarked (Teach Yourself Programming in 10 Years!), and then I downloaded an edited reprint of an article called "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David Goldberg....

Appreciate the breadth and depth of knowledge being shared!

Eddie Gerlach
Greenhorn

Eddie Gerlach wrote:and then I downloaded an edited reprint of an article called "What Every Computer Scientist Should Know About Floating-Point Arithmetic" by David Goldberg....

It seems like you're well on your way. BTW, that link is so well known among us know-it-alls, we just call it "Goldberg" (and the "10 years..." one is often just called "Norvig").

Another one you might be interested in (maybe in a few months time if not now) is Write Dumb Code. It's the Java blueprint for KISS.

Winston

It didn’t say engaged. Read it carefully

Eddie Gerlach wrote:Appreciate the breadth and depth of knowledge being shared!

While you're at it Eddie you may want to fix your problem (har) by using java.math.BigDecimal. You might check out the math package because it has a few nice things to help you control rounding, etc.

I'm not sure why BigDecimal is not one of the standard data types. Can anybody here comment on that?

Paul Witten wrote:I'm not sure why BigDecimal is not one of the standard data types. Can anybody here comment on that?

BigDecimal is very slow, so it should only be used when there is a good engineering justification.

Its great for doing things like multiplying numbers that are thousands of bits long, often done in cryptography. Its total overkill for more usages of money/currency or engineering.

Java also hamstrung it by disallowing operator overloading, so BigDecimal code tends to be much less readable than math expressions with primitives.

Mike Simmons wrote:Java also hamstrung it by disallowing operator overloading, so BigDecimal code tends to be much less readable than math expressions with primitives.

You meant to write: Java is blessed by being designed to disallow operatore overloading, which was tried in Ada and C++ without success.

And also, BigDecimal isn't a magic wand which takes away all the problems associated with floating point representations. For example, when you divide one BigDecimal number by another, you have to decide how many decimal places you plan to keep in the result. And you have to decide which rounding rules apply to the last decimal place. In the end you have a different set of problems than if you had chosen to use floating point.

(And that means that it isn't possible to have an ordinary "/" operator which applies to two BigDecimals.)

Pat Farrell wrote:

Mike Simmons wrote:Java also hamstrung it by disallowing operator overloading, so BigDecimal code tends to be much less readable than math expressions with primitives.

You meant to write: Java is blessed by being designed to disallow operatore overloading, which was tried in Ada and C++ without success.

Oddly enough, no I didn't. While the excesses of unrestricted overloading are good to have avoided, the almost complete ban on it in Java (with string concatenation via + as a tiny exception) does result in much less readable math code, in my opinion. They could have achieved much better readability with some restricted overloading, e.g. mapping "+" to a .add() or .plus() method. Not that I expect things to change now - I was just adding the readability issue to the answer to Paul Witten's question.

I thought it is BigInteger which they use in cryptography.