Some programmers use floats like this
CGFloat itemsHeight = [m_subscriptions count] * 97.f;
and some use floats like this
CGFloat itemsHeight = [m_subscriptions count] * 97.0f;
Is there any side affect in dropping the zero?
No, trailing zeros make no difference: the value of your floating point constant would remain the same. You do need a dot in there, because otherwise the compiler would report a syntax error. In other words, [m_subscriptions count] * 97f will not compile.
There's no side effect. Those are both literal notations for the same number.
Whether you use 0.0, .0, or 0.0f or even 0f does not make much of a difference. (There are some with respect to double and float)
If you are initializing a variable then it make no sense. compiler does all the cast for you.
float a = 0; //Cast int 0 to float 0.0
float b = 0.0; //Cast 0.0 double to float 0.0 as by default floating point constants are double
float c = 0.0f // Assigning float to float. .0f is same as 0.0f
But if you are using these in an expression then that make a lot of sense.
6/5 becomes 1
6/5.0 becomes 1.2 (double value)
6/5.0f becomes 1.2 (float value)
so the basic difference is as :
1.0 or 1. is a double constant
1.0f is a float constant
Without a suffix, a literal with a decimal in it (199.0) will be treated as a double-precision floating-point number. If you assign or pass that to a single-precision variable or parameter, the compiler will (should) issue a warning. Appending f tells the compiler you want the literal to be treated as a single-precision floating-point number.
Related
What is the correct way to perform this operation?
399.9 / 100
What I would expect to see is
3.999
but the result is
3.9989999999999997
The result you see is correct, it's just not what you want.
Doubles are not precise values. The double you get by writing 399.9 is actually the precise value.
399.8999999999999772626324556767940521240234375
That's the closest available double to the exact value 399.9. Any other double is at least as far away from 399.9 as that.
Then you divide by 100. Again, the result is not precise, but the closest double has the exact value
3.99899999999999966604491419275291264057159423828125
That differs from what you would get by writing 3.999, which is the exact value:
3.999000000000000110134124042815528810024261474609375
At every step, the double operations have minimized the error, but because you are doing multiple steps, the final result diverges from the double closest to the mathematical result.
What you need to do depends on what your actual requirements are.
If you want to always calculate with two significant digits, then I'd just multiply my numbers with 100 and do all the operations as integer operations, until the very last division by 100.
If you have an intermediate result and wants to round it to two digits, I'd do what Fy Z1K says:
result = (result * 100).round() / 100;
import 'dart:math';
double roundDouble(double value, int places){
double mod = pow(10.0, places);
return ((value * mod).round().toDouble() / mod);
}
then you would basically get
double num1 = roundDouble(12.3412, 2);
// 12.34
double num2 = roundDouble(12.5668, 2);
// 12.57
double num3 = roundDouble(-12.3412, 2);
// -12.34
double num4 = roundDouble(-12.3456, 2);
// -12.35
To make decimal operations you can use the decimal package.
final d = Decimal.parse;
print(d('399.9') / d('100')); // => 3.999
hi I have a big doubt of using floats for divisions,
here the test code::
- (void)chuza
{
float option1 = 0;
float option2 = 0;
option1 = 100/50;
option2 = 50/100;
NSLog(#"option1 :: %f",option1);
NSLog(#"option2 :: %f",option2);
}
So,
I get:
2012-10-19 16:21:45.405 Project[2023:14f03] option1 :: 2.000000
2012-10-19 16:21:45.405 Project[2023:14f03] option2 :: 0.000000
so my question is:
why would the float like when
denominator > numerator
but doesnt like
numerator > denominator ??
Thanks!
That looks a lot like integer division to me since you are dividing two integer numbers. When dividing two integers (in most if not all programming languages) ignores the remainder of the division.
Think of how that line is being evaluated. First the integer division is calculated and then the integer result is cast to a float to be stored in the float variable.
Note that integers don't store any decimals at all so even 0.999 as an integer would be 0. It's not a problem about rounding.
It's also not about the denominator being bigger than the numerator. Try dividing 100/30 and the result will be 3, not 3.33333.. as it would be for float division.
You can solve this by casting the numbers to floats or making sure they are float numbers.
Casting
option2 = ((float)50/(float)100);
Dividing floats
option2 = 50.0f/100.0f;
Neither 100 nor 50 are floats, they're integers. That means you're doing integer division and assigning the result to a floating point variable. Since integer division truncates (throws away fractional results), 50/100 yields 0. 100 is divisible by 50, which which is why you get the 2.000000 result. Try your program with 75 and 100, and you'll see there's more at work than just which direction the division goes.
It's treating your numbers as integers, performing the division and then putting the result into a float.
Try this option2 = 50.0f/100;
UInt64 intValue = 999999900;
float tt = intValue;
NSLog(#"float tt = %f", tt);
the output result is "float tt = 999999872", as you can see the UInt64 convert to float lose something, the Max float is bigger than 999999900, so I think the value 999999900 can be cast to float, so my question is why lose 28 in iOS?
float has a limited amount of precision. It's not the size of the number, it's the number of significant digits (9 in this case).
Use double instead of float to get more precision.
UInt64 intValue = 999999900;
double tt = intValue;
NSLog(#"double tt = %f", tt);
Why are you using float and not double? Has nobody told you that float has very limited precision (around 7 digits) while double has about 15 digits?
As a rule, you should NEVER use float instead of double unless you yourself can give a reasonable explanation why float would be more suitable than double.
So your question is: Why do I lose precision when I intentionally throw away 8 digits and precision, and what can I do? The answer is very simple: You lost precision because you threw it away yourself. Use double instead of float.
Im obtaining an int value from UITextField [self.dbRef.text intValue];
I want to then format that value so I can add a decimal place that precceds the number ie. If [self.dbRef.text intValue]; returns 4 i need that value to be 0.04
So far I have tried various ways including
float Y = ([self.dbRef.text intValue]/100);
slice.value = Y;
NSLog(#"float Y value = %f",Y);
returns zero
NSString* formatedTotalApplianceString = [NSString stringWithFormat:#"0.%#", self.dbRef.text];
NSLog(#"formated string = %#",formatedTotalApplianceString);
int totalAppliances = [formatedTotalApplianceString intValue];
NSLog(#"Resulting int value = %d",[formatedTotalApplianceString intValue]);
slice.value = totalAppliances;
NSLog(#"total appliances int value = %d",totalAppliances);
returns zero
You're doing an integer division, so the 0 value is correct in that context as integers cannot represent fractions (unless you're doing fixed point arithmetics, but that's a different can of worms). You need to do a floating point division, for example:
float Y = ([self.dbRef.text floatValue]/100.0f);
Either the [self.dbRef.text floatValue] or the 100.0f will turn this into a float division, because if the other side would be an int it would automatically get casted to a float. But the "best" way is to have both values of the same type.
Change
float Y = [self.dbRef.text intValue]/100;
to
float Y = ((float)[self.dbRef.text intValue])/100;
in your first variant.
Dividing int by int returns you int result even if then you assign it to float. 4/100 = 0 in such case.
The problem with [self.dbRef.text intValue]/100 is that it's an integer division. It drops the fraction. One way to work around it is to divide by 100.0:
[self.dbRef.text intValue]/100.0
However, this is not the most efficient way of doing it if all you need is adding a zero in front of a fraction: you could avoid float altogether by padding your printed int to two positions with leading zeros:
// If text is 4, the code below prints 0.04
NSLog(#"0.%02d", [self.dbRef.text intValue]);
The first code returns zero because you are performing an integer division, which produces an integer result. You should cast the value to a float.
The second code also returns zero because you're asking for the intValue of a floating point value. So the decimal part will be discarded.
NSString has also a floatValue method, you should use it to get a floating value. Once divided by 100 you will still have a floating point value (in a division if the quotient or the dividend is a float and the other an integer, the integer gets promoted to float):
float Y = ([self.dbRef.text floatValue]/100);
slice.value = Y;
When I run the following code ,
NSString* s= #"10000000.01";
float f = [s floatValue];
double d = [s doubleValue];
if(f > 10000000)
{
NSLog(#"Over Value");
}
else {
NSLog(#"OK Float");
}
if(d > 10000000)
{
NSLog(#"Over value");
}
else {
NSLog(#"OK Double");
}
The response is like following.
2013-04-19 17:07:29.284 float[2991:907] OK Float
2013-04-19 17:07:29.287 float[2991:907] Over value
Why float value changed to 10000000.00 instead of 10000000.01 ?
float is 32-bit while double is 64-bit. A float has fewer significant digits than double.
A float value doesn't store enough to hold the 10 digits of your 10000000.01.
Also see Difference between float and double for more details. That is about C/C++ but it applies to Objective-C as well.
Double
Represents a 64-bit floating-point number.
Has a precision of at least 15 decimal digits.
Float
Float represents a 32-bit floating-point number.
precision of Float can be as little as 6 decimal digits.
The appropriate floating-point type to use depends on the nature and range of values you need to work with in your code. In situations where either type would be appropriate, Double is preferred.
Precision
Float - 32-bit (7 digits) floating point precision
Double - 64-bit (15 digits) floating point precision
One bit is allocated for signed bit.
Memory requirement
Float - 4 bytes
Double - 8 bytes
Range
Float - within 1.2E-38 to 3.4E+38
Double - within 2.3E-308 to 1.7E+308