I was trying to add some CGFloat values recursively in my program. And I just realized in one particular scenario the total generated was incorrect. To ensure I had nothing wrong in my program logic, I created a simple example of that scenario (see below) and this printed the same wrong value.
CGFloat arr[3] = {34484000,512085280,143011440};
CGFloat sum = 0.0;
sum = arr[0] + arr[1] + arr[2];
NSLog(#"%f",sum);
int arr1[3] = {34484000,512085280,143011440};
int sum1 = 0.0;
sum1 = arr1[0] + arr1[1] + arr1[2];
NSLog(#"%d",sum1);
The first NSLog prints 689580736.000000...while the correct result 689580720. However the second NSLog prints the correct result. I am not sure if this is a bug or if I am doing something wrong.
Thanks,
Murali
CGFloat is a single precision float on 32 bit targets such as iOS - it only has a 23 bit mantissa, i.e. around 6 - 7 significant digits. Use a double precision type if you need greater accuracy.
You should probably read David Goldberg's What Every Computer Scientist Should Know About Floating-Point Arithmetic before proceeding much further with learning to program.
Related
I'm trying to calculate the value of n that solves the problem below. I am not exactly sure where I am messing up. I tried using a do while loop also, but I am having trouble figuring out the logic error. Could anyone assist?
If S = √ (6*( 1+1/2^2+1/3^2 +1/4^2 + 1/5^2 + ... ) ) = (pi^2)/6, after how many terms will the sum be equal to PI to 6 decimal places. PI to 6 decimal places is 3.141592. The relevant part of my code is shown below:
double s = 0;
for(int n=1;abs(sqrt(6*s) - 3.141592) >= pow(10,-6);n++) {
s += (1/(pow(n,2)));
NSLog(#"%i",n);
}
int abs(int i)
computes the absolute value of an integer. Therefore in
abs(sqrt(6*s) - 3.141592)
the floating point number sqrt(6*s) - 3.141592 is converted to an int
first, which gives zero as soon as the absolute value of this number is less than one.
You want to use fabs() instead.
I am puzzled. I have no explanation to why this test passes when using the double data type but fails when using the float data type. Consider the following snippet of code.
float total = 0.00;
for ( int i = 0; i < 100; i++ ) total += 0.01;
One would anticipate total to be 1.00, however it is equal to 0.99. Why is this the case? I compiled with both GCC and clang, both compilers have the same result.
Try this:
#include <stdio.h>
int main(){
float total = 0.00;
int i;
for (i = 0; i < 100; i++)
total += 0.01;
printf("%f\n", total);
if (total == 1.0)
puts("Precise");
else
puts("Rounded");
}
At least on most machines, you'll get an output of "Rounded". In other words, the result simply happens to be close enough that when it's printed out, it's rounded so it looks like exactly 1.00, but it really isn't. Change total to a double, and you'll still get the same.
The value for 0.01 in decimal is expressed as the series: a1*(1/2) + a2*(1/2)^2 + a3*(1/2)^4 + etc. where aN is a zero or one.
I leave it to you to figure out the specific values of a1, a2 and how many fractional bits (aN) are required. In some cases a decimal fraction cannot be represented by a finite series of (1/2)^n values.
For this series to sum to 0.01 in decimal requires that aN go beyond the number of bits stored in a float (full word of bits minus the number of bits for a sign and exponent). But since double has more bits then 0.01 decimal can/might/maybe (you do the calculation) be precisely defined.
Simple question, I know there must be a correct way to do this. I have a CGFloat that increases in increments of 1/16. I want to determine when this value becomes a whole number.
For lack of knowing the right way I am coming up with ideas like having another variable to keep track of the number of iterations and mod 16 it.
While you generally can't count on fractional floating point numbers to sum up to whole numbers, your case is exception to the rule since 1/16 is 2^(-4) and this number can be represented by float precisely:
- (void)testFloat
{
float a = 0.0f;
while (a != 2.0f) {
a += 0.0625f;
}
NSLog(#"OK!");
}
It's better to do it the other way around, i.e. use an integer loop counter and convert this to a float:
for (int i = 0; i < 100; ++i)
{
float x = (float)i / 16.0f;
if (i % 16 == 0)
{
// if x is whole number...
}
}
Floating point arithmetic is inexact so you can't count on the value of your variable ever being exactly 2.0000.
"For lack of knowing the right way I am coming up with ideas like having another variable to keep track of the number of iterations andmod 16 it."
This is a wonderful idea.
I'm using the standard equation of distance / speed = arrival time. This works fine, but the answer is a float number and most people would find it awkward to convert something like 1.75 hrs to be 1 hr and 45 minutes.
I want to take that final float number result and extract the hour(s) separately from the minutes as integers.
Here is what I've tried:
-(IBAction)calculate:(id)sender {
float spd=[speed.text floatValue];
float dist=[distKnots.text floatValue];
//this give me the answer as a float
float arr=(dist/bs);
//this is how I showed it as an answer
//Here I need to convert "arr" and extract the hours & minutes as whole integers
arrivalTime.text=[NSString stringWithFormat:#"%0.02f", arr];
[speed resignFirstResponder];
}
And this is the conversion I tried to do -- and on paper it works, but in code it's full of errors:
int justHours = arr*60;
int justMinutes = (arr*60)-(justHours*60);
//then for the user friendly answer:
arrivalTime.text=[NSString stringWithFormat:#"%n hours and %n minutes", justHours, justMinutes];
I'm new to Objective-C and hoping there is a way to get this to work or a better way altogether to resolve this.
Your arr variable is already measured in hours, so you shouldn't be scaling it, just rounding it down:
int justHours = (int)arr;
and then your minutes is sixty times the (integer) difference between the original and rounded hours (i.e. the fractional part).
int justMinutes = (int)((arr - justHours) * 60);
The int justHours = arr/60; seems to be incorrect, it should be int justHours = arr;.
check the NSNumber numberFormater class. I believe you can wrap your float with time format and the return it to the user.
I am learning Objective-C and have completed a simple program and got an unexpected result. This program is just a multiplication table test... User inputs the number of iterations(test questions), then inputs answers. That after program displays the number of right and wrong answers, percentage and accepted/failed result.
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog(#"Welcome to multiplication table test");
int rightAnswers; //the sum of the right answers
int wrongAnswers; //the sum of wrong answers
int combinations; //the number of combinations#
NSLog(#"Please, input the number of test combinations");
scanf("%d",&combinations);
for(int i=0; i<combinations; ++i)
{
int firstInt=rand()%8+1;
int secondInt=rand()%8+1;
int result=firstInt*secondInt;
int answer;
NSLog(#"%d*%d=",firstInt,secondInt);
scanf("%d",&answer);
if(answer==result)
{
NSLog(#"Ok");
rightAnswers++;
}
else
{
NSLog(#"Error");
wrongAnswers++;
}
}
int percent=(100/combinations)*rightAnswers;
NSLog(#"Combinations passed: %d",combinations);
NSLog(#"Answered right: %d times",rightAnswers);
NSLog(#"Answered wrong: %d times",wrongAnswers);
NSLog(#"Completed %d percent",percent);
if(percent>=70)NSLog(#"accepted");
else
NSLog(#"failed");
[pool drain];
return 0;
}
Problem (strange result)
When I input 3 iterations and answer 'em right, i am not getting of 100% right. Getting only
99%. The same count I tried on my iPhone calculator.
100 / 3 = 33.3333333... percentage for one right answer (program displays 33%. The digits after mantissa getting cut off)
33.3333333... * 3=100%
Can someone explain me where I went wrong? Thanx.
This is a result of integer division. When you perform division between two integer types, the result is automatically rounded towards 0 to form an integer. So, integer division of (100 / 3) gives a result of 33, not 33.33.... When you multiply that by 3, you get 99. To fix this, you can force floating point division by changing 100 to 100.0. The .0 tells the compiler that it should use a floating point type instead of an integer, forcing floating point division. As a result, rounding will not occur after the division. However, 33.33... cannot be represented exactly by binary numbers. Because of this, you may still see incorrect results at times. Since you store the result as an integer, rounding down will still occur after the multiplication, which will make it more obvious. If you want to use an integer type, you should use the round function on the result:
int percent = round((100.0 / combinations) * rightAnswers);
This will cause the number to be rounded to the closest integer before converting it to an integer type. Alternately, you could use a floating point storage type and specify a certain number of decimal places to display:
float percent = (100.0 / combinations) * rightAnswers;
NSLog(#"Completed %.1f percent",percent); // Display result with 1 decimal place
Finally, since floating point math will still cause rounding for numbers that can't be represented in binary, I would suggest multiplying by rightAnswers before dividing by combinations. This will increase the chances that the result is representable. For example, 100/3=33.33... is not representable and will be rounded. If you multiply by 3 first, you get 300/3=100, which is representable and will not be rounded.
Ints are integers. They can't represent an arbitrary real number like 1/3. Even floating-point numbers, which can represent reals, won't have enough precision to represent an infinitely repeating decimal like 100/3. You'll either need to use an arbitrary-precision library, use a library that includes rationals as a data type, or just store as much precision as you need and round from there (e.g. make your integer unit hundredths-of-a-percent instead of a single percentage point).
You might want to implement some sort of rounding because 33.333....*3 = 99.99999%. 3/10 is an infinite decimal therefore you need some sort of rounding to occur (maybe at the 3rd decimal place) so that the answer comes out correct. I would say if (num*1000 % 10 >= 5) num += .01 or something along those lines multiply by 100 moves decimal 3 times and then mod returns the 3rd digit (could be zero). You also might only want to round at the end once you sum everything up to avoid errors.
EDIT: Didn't realize you were using integers numbers at the end threw me off, you might want to use double or float (floats are slightly inaccurate past 2 or 3 digits which is OK with what you want).
100/3 is 33. Integer mathematics here.