-3

My question is more about Why in C++,C# and VB

std::cout<<2.2f*3.0f<<std::endl; //prints 6.6

And in Python, Java and Ruby

2.2*3.0 //prints 6.6000000000000005

I'm very familiar with floating point representation in memory. I checked that in fact 2.2 cannot be represented precisely in memory with single precision.

But still why do C++,C# and VB cut-out the irrelevant part of the result when printing the value while the others do not?

Sam Aleksov
  • 1,201
  • 6
  • 12
  • 1
    its the inherint problem with floats ... they are not exact... this problem exists in pretty much every language imaginable ... try `from decimal import Decimal;Decimal("2.2")*Decimal("3.0")` – Joran Beasley Oct 17 '13 at 17:40
  • 3
    try reading through this: http://stackoverflow.com/questions/406361/floating-point-limitations – Corley Brigman Oct 17 '13 at 17:41
  • 1
    http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html –  Oct 17 '13 at 17:41
  • 1
    Look up floating point arithmetic on google. The short answer is that your computer is not able to accurately represent the number 6.6. This is also the reason why you should never do == comparisons with floats. – rasmusgreve Oct 17 '13 at 17:42
  • 1
    I like the links in this question: [Python math is wrong](http://stackoverflow.com/questions/11950819/python-math-is-wrong). – DSM Oct 17 '13 at 17:42

1 Answers1

6

This is not to do with Python, it's just the way computers handle floating-point arithmetic.

Imagine trying to write down 1/3 exactly as a decimal in base 10 - you can't as you don't have an infinite amount of time or paper. There are an infinite number of 3s, so any decimal representation can only ever be an approximation.

Similarly, computers don't have an infinite amount of memory, so they can't represent certain fractions exactly (although these are different fractions as computers work in base 2). So in this case, the nearest the computer can get to 2.2*3.0 is 6.6000000000000005. This isn't to do with the multiplication, it's becuase the computer can't store 2.2 completely accurately. However, most of the time, the degree of accuracy given is near enough.

If you need perfect accuracy in Python, you can use the Decimal module.

In relation to problems this causes in "precise business logic", the answer is usually that when dealing with money, don't encode £1.23 as 1.23, but as 123 (pence). However, you may need to do something more complicated when dealing with dividing amounts of money, but this something else shouldn't just be using floats.

In answer to your edited question, it's just that C++ doesn't display as much of the number as Python. It doesn't store it more accurately.

"But still why do C++,C# and VB cut-out the irrelevant part of the result when printing the value while the others do not?"

Because they do. The people who implemented those languages made a different choice to those who implemented other languages. They weighed up the benefits of printing it out fully (it means you don't forget that floating point arithmetic is inaccurate) with the downsides (it is sometimes more difficult to see what the effective result is, shortening it gives an accurate result much of the time) and came to different conclusions.

rlms
  • 10,650
  • 8
  • 44
  • 61
  • 1
    on a side note sometimes they can store an accurate representation (ie if he used 2.5 instead of 2.2) – Joran Beasley Oct 17 '13 at 17:47
  • Well I guess recent projects involving C# and VB made exactly this. They made me forget floating point representation is innacurate by rounding the values. Thank you for answering both the original question and the edit and not going "oh and you're experienced?" ! – Sam Aleksov Oct 19 '13 at 21:01