1

I read the pset discussion and watched the linked video at Greedy.c works for all numbers except 4.2. Great stuff that left me with one question:

Is there a set of conditions or a formula that will predict which base-10 numbers will have difficulty being stored by the computer when converted into binary form?

The obvious examples are any numbers that continue add infinitum (for example .333333..., .44444.....) but what about numbers such as that in Pset1/Greedy (i.e. 4.2)? How can I predict the inaccuracy problems before they happen?

2

Non-integer decimal values are represented with tenths, hundredths, thousandths, etc. This corresponds to negative powers of 10, the base of the system.

Non-integer binary values are similarly represented using negative powers of 2, which you could think of as halves, quarters, eighths, etc.

You may or may not deal with floating-point data on a regular basis, depending what you end up doing with the computer science knowledge you gain from cs50x. The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic can be a useful resource/reference. It has a page about doing comparisons and another page to explain how binary fractions work (emphasis mine):

Specifically, binary can only represent those numbers as a finite fraction where the denominator is a power of 2. Unfortunately, this does not include most of the numbers that can be represented as finite fraction in base 10, like 0.1.

Because of this, the best approach by far is to assume that every floating-point value is inaccurate at some degree of precision and to always take appropriate precautions when dealing with float type variables or floating-point numeric literals.

Those precautions, depending on the nature of the program, might be:

  • Convert the numbers to integers for comparisons and calculations, then convert back to floating-point when you need to display results. This is the suggested approach for pset1, where it works because you only care about two decimal places to count dollars and cents and the calculations are very simple. It's not a good general solution though, because sometimes you need many decimal places, or you don't know how many you need, or the calculations are more involved.
  • Compare numbers by checking that the absolute value of their difference is small instead of checking for exact equality, as explained here on Stack Overflow. You can use this method with inequalities as well by first checking the "nearly equal" condition and then checking the greater-than or less-than condition separately.
  • Don't use floats if you don't have to. This shouldn't need a lot of explanation, but it does need good judgment – something you will develop with experience.

Questions about working with floating point values are asked so frequently on Stack Overflow that we had a discussion earlier this year about cleaning up one of the better existing ones into a FAQ-style reference. The favored candidate for this was Why Are Floating Point Numbers Inaccurate? but only a certain amount of work has been done to make it clear and readable so far.

1
  • +1 for the floating point guide. – sinister Oct 2 '14 at 6:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .