Mark
asked on
math with BigDecimal, stuck
I want to do: <%= 100.0 * rs.getBigDecimal("DROPirat
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>><%= 100.0 * rs.getBigDecimal("DROPirat
Problem with that is that it constrains precision, which defeats the object of using BigDecimal
Problem with that is that it constrains precision, which defeats the object of using BigDecimal
why get it as a BigDecimal in the first place, would appear to be just complicating things unless u have a specific need:
<%= 100.0 * rs.getDouble("DROPirate") %>
you can use a DecimalFormat (or format tag) to then format it as required.
<%= 100.0 * rs.getDouble("DROPirate") %>
you can use a DecimalFormat (or format tag) to then format it as required.
jmarkfoley, i of course am assuming you are not getting BigDecimal from the ResultSet for no good reason
ASKER
CEHJ: Yes, decimal for a reason. The data is stored in the SQL server database as decimal and converting it to double does introduce rounding errors. I have to accumulate a running total to output and the rounding errors on floating point can add up to more than a few cents. So, I'd rather do the painful manipulation of BigDecimal. Your solution worked. I had to include:
<%@ page import="java.math.BigDecim
but, I have a concern. If I do 'new BigDecimal(...' for each row I retrieve, am I not creating lots of new BigDecimal objects?
<%@ page import="java.math.BigDecim
but, I have a concern. If I do 'new BigDecimal(...' for each row I retrieve, am I not creating lots of new BigDecimal objects?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
:-)
> The data is stored in the SQL server database as decimal and converting it to double does introduce rounding errors.
you're going to get rounding issues whatever you use as you can only display it to a fixed number of places :)
you're going to get rounding issues whatever you use as you can only display it to a fixed number of places :)
ASKER
objects: thanks for your feeback. You've been a big help on lots of other questions I've posted. I appreciate you insights.
Regarding rounding on decimals. The problem in converting decimal to double is that often things like 23.45 get converted to 23.4499999 or 23.450001 which is no problem once individually formatted. The problem comes in when those values are aggregated in a sum. Depending on how many values are added, they can accumulate several hundredths of rounding error. If a value is stored in database as decimal with only two digits of precision, then you will never get rounding errors to a even a third digit, let alone in the second digit. I've had experience both ways, esp. with languages like C or shell CGI scripts that don't have a decimal datatype. This is one reason why COBOL hung around so long - native decimal datatype.
Regarding rounding on decimals. The problem in converting decimal to double is that often things like 23.45 get converted to 23.4499999 or 23.450001 which is no problem once individually formatted. The problem comes in when those values are aggregated in a sum. Depending on how many values are added, they can accumulate several hundredths of rounding error. If a value is stored in database as decimal with only two digits of precision, then you will never get rounding errors to a even a third digit, let alone in the second digit. I've had experience both ways, esp. with languages like C or shell CGI scripts that don't have a decimal datatype. This is one reason why COBOL hung around so long - native decimal datatype.
in this case your not aggregating them, you're just displaying them so creating a BigDecimal is unnecessary overhead.
>>you can only display it to a fixed number of places :)
That's not the case with, and is really the whole point of, BigDecimal.
That's not the case with, and is really the whole point of, BigDecimal.
<%= 100.0 * rs.getBigDecimal("DROPirat