1

Possible Duplicate:
CGFloat addition bug?

I have some code where I'm doing a lot of multiplying and dividing of CGFloats in order to figure out the correct dimensions for transformations. I notice sometimes when I'm suppose to get a value of 320, I'll get 320.00000092 instead. Can anyone explain why this is happening and how to correct it? Is it suppose to be doing this? Here is some sample code where it's possible the problem might be happening:

- (void) setMinimumSize
{
    CGSize superViewSize = self.superview.bounds.size;
    CGSize size = self.frame.size;

    CGFloat xScale = superViewSize.width / size.width;
    CGFloat yScale = superViewSize.height / size.height;

    CGFloat minimumScale = MIN(xScale, yScale);
    self.minimumSize = CGSizeMake(size.width * minimumScale, size.height * minimumScale);
}

- (void) scaleToMinimumSize
{
    self.transform = CGAffineTransformScale(self.transform, self.minimumSize.width / self.frame.size.width, self.minimumSize.height / self.frame.size.height);
}
Community
  • 1
  • 1
Ser Pounce
  • 14,196
  • 18
  • 84
  • 169

1 Answers1

4

Don't compare for equality, won't work for float (or double), rather compare the difference against some delta that suits your needs for accuracy

This is always an issue with decimal and floating points numbers.

Ask a middle school student (1/3.0)*3.0, all will say 1. Computer says 0.999999.

You cant expect, most of the time, 0 to be 0.000000 it will never be near to that.

EDIT:

If float is in so much of use, you should read this one http://en.wikipedia.org/wiki/IEEE_754-2008

And also What Every Computer Scientist Should Know About Floating-Point Arithmetic,

Anoop Vaidya
  • 46,283
  • 15
  • 111
  • 140
  • 1
    That's not an explanation (as asked for in the question). Also, the stereotypical "equality won't work for float" is neither correct nor an issue in this case. – Nikolai Ruhe Jan 18 '13 at 09:56
  • As OP "he exptects 320,but get 320.00000092 instead" that means he is trying to compare both the values. Also why 320 comes as 320.00000092 was another question. for that I menationed you cannot get 0.0000000 accuracy in floats. – Anoop Vaidya Jan 18 '13 at 10:03
  • I don't see a comparison in @CoDEFRo's code. But I do see him asking for an explanation. – Nikolai Ruhe Jan 18 '13 at 10:10
  • @NikolaiRuhe : I have added few more links and description, please let me know if it is fine – Anoop Vaidya Jan 18 '13 at 10:22
  • 1
    You just copied other people's answers (from here http://stackoverflow.com/a/5334849/104790 and here http://stackoverflow.com/a/10335601/104790) without mentioning the sources. Please understand that this is not welcome on SO. – Nikolai Ruhe Jan 18 '13 at 10:39
  • @NikolaiRuhe : sorry, from next time i wont copy anyone's answer and try to create my own new answers, explanations, logics etc ;( – Anoop Vaidya Jan 18 '13 at 10:48
  • 1
    Actually, 1/3.0 * 3.0 *is* exactly 1.0 when evaluated in IEEE-754 double-precision, and result that should be exactly zero are among the most likely to have noticeable errors. Floating-point is subtle and generic answers that do not affect the specific question being asked are usually incorrect. – Stephen Canon Jan 18 '13 at 10:51
  • @StephenCanon: OK... I am deleting my answer. – Anoop Vaidya Jan 18 '13 at 10:55
  • @NikolaiRuhe : OK... I am deleting my answer. – Anoop Vaidya Jan 18 '13 at 10:55
  • 1
    Your statement "Whenever you want a floating point value with some precision, you can take an integer and multiply it" also is wrong for many operations. – Nikolai Ruhe Jan 18 '13 at 13:51