Slick2D MouseWheel and Decimal Rounding

[Vladiedoo]

Hi, for the following Slick2D code I have two questions.

(zoom is a float and zoom2 is a double)

1   2   3   4   5   6   7   8   9   10

public void mouseWheelMoved(int change) {       if (change >= 120) {          Info.zoom += .1;          Info.zoom2 += .1;       } else {          Info.zoom -= .1;          Info.zoom2 -= .1;       }       System.out.println(Info.zoom + " " + Info.zoom2);    }

• I've seen this happen before when I used Java2D but why is "int change" measured by 120s?
• In the Console my numbers eventually look like .7999995 instead of .8 or .2000000000000015 instead of 2, why does this happen, is there a way to fix this?

Thanks for any help you guys can provide.

[ra4king]

1. Don't know, this might be mouse-specific and there might be a method that returns a resolution somewhere
2. That's basic floating point errors, you will learn to love them

[Vladiedoo]

1. Don't know, this might be mouse-specific and there might be a method that returns a resolution somewhere
2. That's basic floating point errors, you will learn to love them

1. I remember testing two different mouses but got the same numbers.
2. Does that mean I'd want to use whole numbers and then subtract if I wanted decimal accurate numbers?

Games published by our own members! Check 'em out!

[ra4king]

There's no way you can get exactly accurate numbers. If you see how floating point values are represented on the byte-level, you'll understand

[Vladiedoo]

Thanks for replying but this sparks some questions. I'll be sure to do some research on byte level representation but if you don't mind me asking..

• I'm sure, for example, NASA doesn't use Java but how would they calculate decimal accurate numbers? Wouldn't they need to do that for simulations and calculations?
• Is this a Java specific issue or a issue that computers as a whole share? Also my TI-84 Calculator does decimal precision just fine(or so I think), how does it work around it?

[Orangy Tang]

• I'm sure, for example, NASA doesn't use Java but how would they calculate decimal accurate numbers? Wouldn't they need to do that for simulations and calculations?
• Is this a Java specific issue or a issue that computers as a whole share? Also my TI-84 Calculator does decimal precision just fine(or so I think), how does it work around it?

For arbitrary precision numbers you'd use something like BCD ( http://en.wikipedia.org/wiki/Binary-coded_decimal ). If you're using java then there's BigDecimal ( http://docs.oracle.com/javase/1.5.0/docs/api/java/math/BigDecimal.html ) which handles all the icky details for you.

However, unless you're sending probes to mars or handling large quantities of money these are probably overkil. Really you need to read up on how floating point numbers are represented because it's common to all languages, not just java. This is a pretty comprehensive doc: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

For most game-related stuff you can usually get away with using floats but rounding when displaying, or using integers with a fixed decimal place (ie. you assume everything is multiplied by, say, 100).

[Vladiedoo]

Awesome, thank you both, this was extremely helpful  .

[ra4king]

Also, your TI-84 calculator most likely is doing some tricks to hide the errors from you. Same with the Windows calculator

[ReBirth]

For user interaction purpose I hide it with formatter

[Grunnt]

@Orangy Tang: thanks! That was very insightful.

Edit:funny, I do know about bits and bytes, but I never really stopped to consider that even doing something as simple as adding two 0.1f floats actually results in a small rounding error:

1   2   3   4   5   6   7

public static void main(String[] args) {       float a = 0;       for (int i = 0; i < 10; i++) {          a = a + 0.1f;       }       System.out.println(a);    }

This gives as output '1.0000001', instead of the - naively - expected '1'.

This makes me happy. Am I weird?

Games published by our own members! Check 'em out!

[Riven]

I'm going to reply to this from a whole other point of view.

You most likely don't want zooming done by adding an subtracting a zoom-factor.

Instead, you want zoom levels, which raise the zoom factor to a certain power:

1   2   3   4   5   6   7   8   9   10   11   12   13

Info.zoomLevel = 0;    public void mouseWheelMoved(int change) {       if (change >= 120) {          Info.zoomLevel++       } else {          Info.zoomLevel--;       }       // each zoom level decreases/increases the zooming with 5%      Info.zoomFactor = Math.pow(1.00 + 0.05, Info.zoomLevel);       System.out.println(Info.zoomFactor);    }

Which instantly gets rid of the accumulation of floatingpoint errors. (!)

[Grunnt]

@Riven, thanks for that advice, I'm also going to take it. This discussion just made me realize the current zoom function in the game I'm working on is flawed (some quick hack I never got around to do properly), even though it works on my machine. This looks like a good way to fix it.