Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
If rounding is required what exactly happens? I was looking in the documentation and it says it just throws an exception, yet in my application it seems to be rounding with half up.
RoundingMode.UNNECESSARY mandates that a BigDecimal does not need to be rounded to fit the scale specified by it.
Here's a sample:
System.out.println(new BigDecimal("1.1").setScale(1, RoundingMode.UNNECESSARY));
1.1 is an exact result, and when the new BigDecimal is created as a result of setScale, it does not need to round the result to get that precise value.
It would also work if you blew out the scale:
System.out.println(new BigDecimal("1.1").setScale(1_000, RoundingMode.UNNECESSARY));
...but, it would break if you tried something like this:
System.out.println(new BigDecimal("1.12").setScale(1, RoundingMode.UNNECESSARY));
The reason for that: you have to round your BigDecimal now in order for you to represent the appropriate scale (1 number after the decimal).
You wouldn't see the behavior if you had your scale larger than the amount of digits after your decimal, but may see another rounding behavior if it was already established on that instance of your BigDecimal. You have complete control over the rounding, so use that judiciously.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I'm working on a software and, at some point in the program, a double becomes NaN which destroys the entire program.
Can I get some help on how to debug a problem like this and how to find the actual line where a double is accidentally set to NaN?
Narrowing down where a NaN occurs can be quite difficult sometimes in a context doing very complex work. The author of Physically-Based Rendering documents a tricky case, for example, where his raytracer was slowed down to a crawl as a result of some expressions evaluating to NaN which caused an excessive amount of computation subsequently. These things can be quite tricky to spot, especially if it's an edge case that only occurs one in a million times.
A handy trick is to rely on the IEEE standard where a variable compared to itself will return false if its value is NaN. This may not work on all compilers so you may want to make sure it does before you sprinkle assertions, but...
boolean is_nan(double val)
{
return val != val;
}
In Java we don't need this trick, however. We already have isNan in java.lang.Double.
With this handy, you can narrow down where a NaN occurs through a process of elimination by doing sanity checks like:
double val = ...;
// after various arithmetical operations
assert !Double.isNan(val);
You can then work your way down (up?) and narrow down exactly what line of code is producing a NaN by adding more granular checks of this sort whenever you hit an assertion failure, taking note of which line of code in which the assertion fails. In very complex scenarios like the raytracer scenario cited where this might only occur one in a million times, this can be a lot quicker than trying to trace everything through a debugger.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
I feel like I'm missing something here, but I'm not entirely certain what and I'm relatively new so I'm having trouble searching for exactly what may be causing it.
java snippet follows:
double testDoublePi = 3.145926
System.out.printf("This one rounds: %.2f\tBut this does not: %.2f", testDoublePi, Math.PI );
"This one rounds: 3.15 But this does not: 3.14"
I expected both to be checking the thousandths digit and rounding accordingly, but that's apparently not the case.
I have a sneaking suspicion it has something to do with testDoublePi being finite vs Math.PI, but I'm not sure. I don't have a particular practical application that would require PI to be rounded offhand, but I figure it'd be important to know what's going on before I get myself in trouble and frustrated later.
What happens is that Pi is not 3.145926.... It is 3.1415926.... They are different:
3.145926 -> 3.15
3.1415926 -> 3.14
^
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I have a problem - is there any possibility to recognize in the text the negative number, that has a minus sign on the right?
E.g. I'm thinking about number like that: 1500.0- (instead of -1500.0).
Thank you in advance for any help.
Not only is it possible, it is actually easier to handle a trailing sign. You just convert the number as usual, continuing while you keep getting digits, then if it ends with a minus sign just negate it. Easier than having to remember a leading sign.
Despite the names of the methods provided in the JDK, this is not 'parsing', it is radix conversion.
You could use charAt or a regular Expression, and many more...
String s = "1500.00-";
if (s.charAt(s.length()-2) == '-'){
//minus on the right.
}
First move the minus (if any) from the end to the start:
num = num.replaceAll("(.*)(-)?$", "$2$1");
The good thing here is that if there's no minus sign at the end, or yjr minus us alteady at the start, nothing change it made.
Then parse it as normal, eg:
double d = Double.parseDouble(num);
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
multiply any 2 numbers. The numbers can be extremely large (i.e. run into hundreds of digits) and are provided as strings.
The expected output is a string which represents the product of the two numbers.
example-
multiply("268435456","524288")="140737488355328"
multiply("12321412423524534534543","0")="0"
Use BigDecimal, which has a multiply method and a constructor which takes a String. It also contains corresponding toString() and toPlainString() methods to get your result as a string.
(If the numbers are always whole numbers, then use BigInteger instead.)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I am trying to to an equation to solve for the amount of time left on a loan based on a specific payment amount (above the normal amount).
The equation is:
nRemaining = ((-log(1-(interestRate / 12) * value2 / value3)) / (log (1+ (interestRate / 12))));
Now obviously this does not work, because I am unsure how to input logarithms.
Your code will work fine, provided a few conditions are met:
If you have to use log that way, place this statement above your class:
import static java.lang.Math.log;
Otherwise, use Math.log() everywhere else you see log.
Technically you don't have to import anything in java.lang, but this is known as a static import - something that should only be done on occasion, and allows you to write your statement a lot cleaner.
Make sure that all of your values are of type double. Otherwise, you'll get integer division, which can lead to NaN for some otherwise inexplicable reason.
Several built-in logarithm methods you might want to use: Math.log, Math.log10, Math.log1p.