-2

I really don't understand the mathematics behind this, can someone please help me understand. Why do they not return the same number?

>>> 9999999999999999 / 16
625000000000000.0
>>> 9999999999999999 // 16
624999999999999
Ged
  • 117
  • 1
  • 5
  • 2
    One is floating point division and the other is integer – talonmies Oct 01 '21 at 09:03
  • This is why you should never assume that some floating point number is *equal* to something, only compare it with an *inequality* like greater/less. Because floating point numbers always have rounding errors – Alexey S. Larionov Oct 01 '21 at 09:10
  • "Why do they not return the same number?" because they are two operations working on different data types. – juanpa.arrivillaga Oct 01 '21 at 09:10
  • I assume you have read what they do. What was unclear about the explanation? – klutt Oct 01 '21 at 09:11
  • Since they're different operators it stands to reason they can produce different results. Which result is causing you confusion? – khelwood Oct 01 '21 at 09:18
  • I understand the issue between floating and floor division, but this brings me onto a bigger issue. Why does 9999999999999999 converted to hex equal "2386F26FC0FFFF" for most (all) decimal to hex calculators, and not "2386F26FC10000"? From my calculations, the least significant hex value should be 0, not F. "9999999999999999 / 16" gives a 0 remainder, while "9999999999999999 // 16" gives a 15 (F in hex) remainder which I assume this is due to the floor rounding. I would have though "0" would be the correct value. – Ged Oct 01 '21 at 17:00

2 Answers2

0

There is a difference between Division and Floor Division.

"/" does the normal floating division.

"//" does the floor division.

For more info check what is floor division.

Also check the documents for difference between these two operators.

Shivendra Pratap Kushwaha
  • 1,961
  • 1
  • 9
  • 22
0

Welcome to the absolute amazing world of Floating Point Math!

You know that computers think in Binary. You know this means that a given bit is either on or off. You know that if you add these together you can make numbers - 0101 = 5 perhaps. When you are dealing with whole numbers, this is very easy.

When you are dealing with whole fractions - ie 1/4th, or 1/2th - this is also very easy. You reserve a few bits for the decimal places, and then you are good. 0101 01 = 5.5 perhaps.

But how do you represent 1/3rd in binary? .333333 repeating. You can't, not accurrately. You could say 0 011 011 011 011 011 100 - with each 11 representing a decimal place (so .333334) above. But then you have to round that last bit up to represent all the stuff beyond it (or i guess it could round down, i don't recall which way it does it - in any cause, it is now a 'whole' decimal and no longer repeating and therefore ... no longer accurate!!!!)

So you come to Floating Point Math. This stuff is complex, but suffice it to say that in the end it is a system designed to do complex math within the limits of Binary, do so QUICKLY and with minimal rounding issues. Q

Quickly being the noted thing here - you can do so quickly or accurately, but not both. With standard data types (such as int/long/double/float) this is good enough for pretty much 95% of all math you'll need to do in programing.

For everything else, if you use a Decimal data type you will have a much much smaller rounding error (decimal data types reserve more bits for the decimal places, allowing it to have more accuracy because the rounding happens at a much much smaller number than other number data types) - Note this is still using Floating Point Math! But it is doing so with a greater degree of accuracy because of the extended amount of bits being used in the decimal places (in the example for 1/3rd above, we did to 6 decimal places. A Decimal data type goes to many more.

Then you have Floor Division, as noted in other answers here, and that is not Floating Point Math - it rounds differently! And therefore, you get a different answer because the strategy for rounding those distant decimal points that are not covered in the binary is different!

lynkfox
  • 2,003
  • 1
  • 8
  • 16