BigDecimal ‘equals’ compares the value and the scale. If you only want to compare values (0 == 0.0) you should use compareTo: BigDecimal.ZERO.compareTo(BigDecimal.valueOf(0.0)) == 0 //true BigDecimal.ZERO.compareTo(BigDecimal.valueOf(0)) == 0 //true See the javadoc. As for the Double comparison, as explained by other answers, you are comparing a Double with an Integer in new Double(0.0).equals(0), which … Read more
Never use a floating point number to represent money. Floating numbers do not represent numbers in decimal notation accurately. You would end with a nightmare of compound rounding errors, and unable to reliably convert between currencies. See Martin Fowler’s short essay on the subject. If you decide to write your own class, I recommend basing … Read more
No. If i is sufficiently large that int(float(i)) != i (assuming float is IEEE-754 single precision, i = 0x1000001 suffices to exhibit this) then this is false, because multiplication by 1.0f forces a conversion to float, which changes the value even though the subsequent multiplication does not. However, if i is a 32-bit integer and … Read more
BigDecimal is immutable, any operation on it including setScale(2, BigDecimal.ROUND_HALF_UP) produces a new BigDecimal. Correct code should be BigDecimal bd = new BigDecimal(1); bd.setScale(2, BigDecimal.ROUND_HALF_UP); // this does change bd bd = bd.setScale(2, BigDecimal.ROUND_HALF_UP); System.out.println(bd); output 1.00 Note – Since Java 9 BigDecimal.ROUND_HALF_UP has been deprecated and you should now use RoundingMode.ROUND_HALF_UP.
However, I wonder, are there any cases, when using == is perfectly fine? Sure there are. One category of examples are usages that involve no computation, e.g. setters that should only execute on changes: void setRange(float min, float max) { if(min == m_fMin && max == m_fMax) return; m_fMin = min; m_fMax = max; // … Read more
Check out clock_gettime, which is a POSIX interface to high-resolution timers. If, having read the manpage, you’re left wondering about the difference between CLOCK_REALTIME and CLOCK_MONOTONIC, see Difference between CLOCK_REALTIME and CLOCK_MONOTONIC? See the following page for a complete example: http://www.guyrutenberg.com/2007/09/22/profiling-code-using-clock_gettime/ #include <iostream> #include <time.h> using namespace std; timespec diff(timespec start, timespec end); int main() … Read more
Assuming that you didn’t set a precision initially, it’s assumed to be the maximum (38). You’re reducing the precision because you’re changing it from 38 to 14. The easiest way to handle this is to rename the column, copy the data over, then drop the original column: alter table EVAPP_FEES rename column AMOUNT to AMOUNT_OLD; … Read more
These accuracy problems are due to the internal representation of floating point numbers and there’s not much you can do to avoid it. By the way, printing these values at run-time often still leads to the correct results, at least using modern C++ compilers. For most operations, this isn’t much of an issue.
Python package keras-metrics could be useful for this (I’m the package’s author). import keras import keras_metrics model = models.Sequential() model.add(keras.layers.Dense(1, activation=”sigmoid”, input_dim=2)) model.add(keras.layers.Dense(1, activation=”softmax”)) model.compile(optimizer=”sgd”, loss=”binary_crossentropy”, metrics=[keras_metrics.precision(), keras_metrics.recall()]) UPDATE: Starting with Keras version 2.3.0, such metrics as precision, recall, etc. are provided within library distribution package. The usage is the following: model.compile(optimizer=”sgd”, loss=”binary_crossentropy”, metrics=[keras.metrics.Precision(), keras.metrics.Recall()])
The short answer is, “use whichever precision is required for acceptable results.” Your one guarantee is that operations performed on floating point data are done in at least the highest precision member of the expression. So multiplying two float‘s is done with at least the precision of float, and multiplying a float and a double … Read more