Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1827
  • Last Modified:

math with BigDecimal, stuck

I want to do: <%= 100.0 * rs.getBigDecimal("DROPirate")) %> Of course, that doesn't work because it gives the error: "The operator * is undefined for the argument type(s) double, BigDecimal". I've tried various things, but my beginner status isn't helping me make much progress. How to I do this?
0
jmarkfoley
Asked:
jmarkfoley
  • 5
  • 3
  • 2
  • +2
2 Solutions
 
CEHJCommented:
Try

<%= new BigDecimal("100").multiply(rs.getBigDecimal("DROPirate")) %>
0
 
ksivananthCommented:
and try this,

<%= 100.0 * rs.getBigDecimal("DROPirate").doubleValue() %>
0
 
CEHJCommented:
>><%= 100.0 * rs.getBigDecimal("DROPirate").doubleValue() %>

Problem with that is that it constrains precision, which defeats the object of using BigDecimal
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
objectsCommented:
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.
0
 
CEHJCommented:
jmarkfoley,  i of course am assuming you are not getting BigDecimal from the ResultSet for no good reason
0
 
jmarkfoleyAuthor Commented:
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.BigDecimal" %>
but, I have a concern. If I do 'new BigDecimal(...' for each row I retrieve, am I not creating lots of new BigDecimal objects?
0
 
shmertCommented:
I wouldn't worry about object creation, it's not really an issue.  If you like, you can create a 100 BigDecimal and reuse it (this is safe, since the BigDecimal is immutable).
0
 
CEHJCommented:
:-)
0
 
objectsCommented:
> 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 :)
0
 
jmarkfoleyAuthor Commented:
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.
0
 
objectsCommented:
in this case your not aggregating them, you're just displaying them so creating a BigDecimal is unnecessary overhead.
0
 
CEHJCommented:
>>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.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 5
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now