I am trying to get percentage but the result is error, i have expression as:
Uper=(Upcount/total)*100;
where Uper is float while Upcount and total is integer i am getting the result Uper=0.
An int divided by an int will result in an int. That could be 0. Multiply 0 * 100, convert to float, and the result is still 0.0. You need at least one of the operands to be floating point before the division will give a floating point result.
Try:
Uper = ((float)Upcount/(float)total)*100.0;
The extra (float) is me being paranoid that this line might be modified in the future without fully understanding the floating-point requirement. The 100.0 is to be explicit about what you want -- a floating point result.
Perhaps changing Upcount or total to float would make more sense.
the division of 2 integers will always result in an integer which is 0 in your case.
To solve this, use the following code:
Uper = ((Double) Upcount) / total * 100
Casting at least 1 member to Double or Float will get the result you want
Related
I am trying to convert float value to 32 bit unsigned long value and facing the problem of loss of value.
long v = (long) f;
Here when f is 4294967295 ((2^32) -1). The conversion to long returns 4294967296 instead of 4294967295 because float conversion is precised to 7 decimal places. I need precision to 9 decimal places. Is there any way to achieve this?
Quote from Java Puzzlers: Traps, Pitfalls, and Corner Cases book:
Floating-point operations return the floating-point value that is closest to their
exact mathematical result. Once the distance between adjacent floating-point values
is greater than 2, adding 1 to a floating-point value will have no effect,
because the half-way point between values won’t be reached. For the float type,
the least magnitude beyond which adding 1 will have no effect is 2^25, or
33,554,432; for the double type, it is 2^54, or approximately 1.8 × 10^16.
So basicly, if you want to represent big numbers, float is a bad idea. Above 2^25 it is not able to represent at least every other integer. It get worse the bigger the number gets.
The best option for you would be to use BigDecimal instead.
Working on a Java class, its making me crazy because this expression is evaluating to zero, I need it to evaluate to a double, then round it down to the nearest int. So what Im trying to get is for days to be a whole number of days, yet when I run it through java it evaluates to 0. When I run it through my calculator it evaluates to the correct value. I would love a fix and an explanation to why this what I already have isn't working.
public int getEventDays(){
//variables
double daysCalc;
int days;
//logic
if (getStatus().equals("filling")){
//this is indented less to fit everything on one line, its not this way in
//the fractions are for unit conversion
daysCalc= Math.floor(((capacity-storage)/(inflow-outflow))*(43560)*(1/3600)*(1/24));
days = (int)daysCalc;
}
else if (getStatus().equals("emptying")){
//this is indented less to fit everything
//the fractions are for unit conversion
daysCalc=Math.floor(((storage-0)/(outflow-inflow))*(43560)*(1/3600)*(1/24));
days = (int)daysCalc;
}
else{
days = -1;
}
return days;
}
Change your code to this :
daysCalc = Math.floor(((storage-0)/(outflow-inflow))*(43560)*(1.0/3600)*(1.0/24));
Explanation:
The right hand expression is returning an integer value. In your case, 1/3600 is rounded to 0, similar to the case of 1/24.
Now by using 1.0 instead of 1, it is giving the unrounded float value of 1/3600.
Your problem is connected with the order of operations within your expression. The parentheses around 1/3600 and 1/24 cause these expressions to be evaluated first - and since each of these divisions has an expression of integer type on either side of the division, it's treated as an integer division. In other words, 1/3600 and 1/24 are both evaluated as integers, to give a result of zero. This means that your arithmetic includes a couple of multiplications by zero, which is why your result is zero.
The simplest fix is to understand that multiplying by the reciprocal of some number is the same as dividing by that number. In other words, you could simplify the calculation to
daysCalc = Math.floor( storage / ( outflow - inflow ) * 43560 / 3600 / 24 );
which will give the correct result, provided storage, outflow and inflow are not all integers.
On the other hand, if storage, outflow and inflow are all integers, then you'll need to make sure that the first division is also not treated as an integer division. You could do this by writing
daysCalc = Math.floor((double) storage / ( outflow - inflow ) * 43560 / 3600 / 24 );
which forces the division to be done with floating point arithmetic; and thereafter, each one of the divisions is done in floating point.
The following code with presence and absence of parentheses produce different output. Why?
System.out.println((double) 3/6); // output 0.5
System.out.println((double) (3/6)); // output 0.0
Because in the first example you are actually doing ((double) 3)/6, and therefore the result is a double too.
In the second one, you are performing an integer division, and then you are casting the result. 3/6 = 0, and (double) 0 = 0.0.
In the first example, you are casting 3 to a double before dividing by an int. According the Java type conversion rules, the output is a double(0.5 in this case).
In the second example, you are dividing an int by an int. Since the number you are dividing is smaller than the number you are dividing with, the answer is zero. Then you are simply casting int 0 to double 0.
I just wanted to calculate the VAT, but when i divide by 100 to obtain the total price (price*VAT/100), but it returns me 0.0. Here's my code:
a.price=sc.nextInt();
a.vat=sc.nextInt();
a.total=a.precio*a.iva/100;
'total' is defines as FLOAT instead of INT
You need to cast the expression to float. I used a float literal here 100.0f.
a.total= a.precio*a.iva/100.0f;
Welcome to integer arithmetic. You want to do this with a float or double value, and quite likely you should be using BigDecimal to maintain precision.
Be careful with "/ 100" operation in Java which can lead you to miscalculations and is an expensive operation (think that the / operation is done in the binary system and not in the decimal system).
I was in a bank project where all the amounts were with two decimals in long values (for example 123.45€ were 12345), so we had to do the same operation as you ("/ 100"). We found that some amounts lead to round calculations... missing a cent (which in banking is unacceptable).
However BigDecimal handles the same operation with a simple "movePointLeft", so I recommend you to use the next code:
total = (BigDecimal.valueOf(price * VAT)).moveLeft(2).doubleValue()
You have to cast your integers, otherwise your result will be computed as an integer before being assigned to a.total. Something like:
a.total = (float)(a.precio) * (float)(a.iva) / 100;
At least on of division operands must be float or double so the result is double. Otherwise the division result is integer.
a.total=a.precio*a.iva/100.0
or if you really need float, you can skip some precision
a.total=(float)(a.precio*a.iva/100.0)
The problem is that what you're putting in your float variable is the result of operations on integers: it's an integer. In other words, a.precio * a.iva / 100 is first evaluated to an integer (that's where you lose precision), and then this integer is assigned to a.total as a float.
You therefore need to specify that the operation a.precio * a.iva / 100 has to be done on floats by casting the integer values.
Change
a.total=a.precio*a.iva/100;
to
a.total= ((float)a.precio)*a.iva/100;
At first glance, my question could seem a bit odd; but casting a double to a float value is not what i want. Since when you cast it, you just lose some precision with respect to the rules defined IEEE-754 and can't achieve actual mapping of a double value to the range of float; it is useless. The following expression works, but it is very very expensive when you have a great amount of input:
float mappedVal = (float)((val * MAX_FLOAT_VALUE + 1) / MAX_DOUBLE_VALUE);
Can I approximate the result to the "mappedVal" mentioned above via some sort of bitwise operations to speed-up the very same computation?
I'm not sure what you're trying to achieve, since some double values are far outside the range of float.
But if you're willing to risk losing values that are too big for float, try this:
float f = new Double(val).floatValue();
Edit: which is exactly the same as casting to float. :)
This maps a double precision value into the float that has the same highest 32 bits:
float mappedVal = Float.intBitsToFloat((int)(Double.doubleToLongBits(val)>>32));
The arithmetic interpretation of this operation is a little complicated though, parts of the exponent are mapped into the mantissa...