There will always be some imprecision when working with floating point numbers (due to the fact that there are an infinite number of them, and only 2^64 possible values of a
double). The imprecision is tiny, of the order of 2^-64, but you need to be careful when comparing with integers or each other using
==. For example, the expression
2 - 1.1 == 0.9 is false since the lhs evaluates to 0.8999999..., even though
2 - 1.2 == 0.8 happens to be true. Because integers are always rounded down, something like 1.99999999 will be converted to 1, and
(int)((2 - 1.1) * 100) == 89. Hence converting from floating point numbers to integers in general isn't a very good idea (especially to be avoided when dealing with money, where
you should do all your arithmetic in pennies using the
long datatype).
In your case, what is your expected result and why do you think the results you're getting are wrong? If I'm scaling a minimum value, in general I'd expect something like the minimum value back, however much I'm scaling it by. If it's out by 1, I wouldn't be worried because we're dealing with minimum values, so the actual difference is insignificant. If you're talking about a sound recording, think about the inaccuracy for minimum values that would have been introduced when it was encoded originally: you're trying to be accurate about some data that wasn't accurate to start with. So using BigDecimals to try to increase accuracy would be pointless.
Python might be using something like a BigDecimal automatically, but it will be, in comparison with Java, very slow.
To put it another way, obviously you'd expect some inaccuracy to enter when you convert from a double to an integer. If you have a value of 2.6, what integer are you expecting? Whether it's 3 or 2, you're going to be "inaccurate" by a large percentage. But this "inaccuracy" will only be a large percentage when dealing with values close to the minimum (i.e. 1).
Incidentally, if you want to round to the nearest integer, rather than rounding down, all you have to do is to add 0.5 before converting to an integer. (Or subtract 0.5 for negative numbers.) This would probably be more appropriate for a sound recording than always rounding down.