Solved Doubles are bigger then they are soposed to be?

Hi guys, I have a weird issue that I have looked around for help fixing and cannot find help. I am making an EXP plugin and my problem is that my doubles are not working right..
After increasing the double by 0.1 three times, the number becomes 0.30000000000000004 instead of 0.3.. I am not sure why? Anyone know? Thanks.

 

post your code?

 

Geekxboy

Code:java

 @EventHandler
public void onBlockBreakEvent(BlockBreakEvent event){
Player player = event.getPlayer();
Block block = event.getBlock();
EXPAPI.setexp(player, EXPAPI.getexp(player) + getworth(block), true);
}
 
public static double getworth(Block block){
Material m = block.getType();
if(m == Material.IRON_ORE){
return 0.5;
}
return 0.1;
}

That is the part of my plugin that edits the levels - and EXPAPI is another class with static methods in it - it just does

Code:java

expdata.put(p.getUniqueId(), amount);

(expdata is the main hashmap and everything is stored with uuids in the config. Amount is the amount (double) from first bit of code.)

EDIT: It works with integers fine... But i need doubles.

 

Beeperdp

This is one of the downfalls of floating-point arithmetic (the basis of almost all arithmetic done on computers today that requires a decimal, represented in Java as float and double). It arises from the fact that 0.3 does not have an exact representation in binary and must be rounded to the nearest viable value. An excerpt from the Wikipedia article on the subject:

Due to this problem with floating point numbers, you can generally never check whether a floating point number is exactly equal to another, or an integer. Instead, a common workaround is to check in a small range around the number for example, in your case:

Code:java

float foo = 0.3f;
 
if( foo >= 0.299 && foo <= 0.3111) {
  // do stuff
}

 

mythbusterma
Thanks for the explanation, but checking in a range will not work for me because the double could be over 50 thousand, which would really be like 51 thousand, etc.. Do you have any way to work around that?

 

Beeperdp

At around 50k the error would still only be around 10^-4 so I think you should be okay, assuming you correct the value so it doesn't stray too far from it's true value.

 

mythbusterma Ok thanks - I think I can just do that.

 

Beeperdp

Alternatively, for absolute precision, Java provides the BigDecimal class that does not suffer from the effects of floating-point arithmetic.

 

mythbusterma thx