• Post Reply Bookmark Topic Watch Topic
  • New Topic

Should I use double or BigDecimal  RSS feed

 
Ranch Hand
Posts: 614
9
BSD Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tony Docherty wrote:Are you sure you want to use Double (or double) to hold a price. Please google for something like "why not use floating point numbers for currency" to find out why this is a really bad idea.

This is a very valid point for currency.

Currently I have a requirement where currency is not involved. There is a member variable "module" which is of type int.
Currently it holds values 1 through 5.
Now as per a new requirement, it should also hold values like 0.5, 1.5, 2.5 etc. and "module" participates only in ADDITION and MULTIPLICATION to a whole number.
So I was thinking of changing the type to BigDecimal.
Is it OK, or there is something more suitable for this?
 
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It entirely depends on what the meaning is of the variable "module" and whether it's OK that the values stored in it are imprecise (which is what you get when you use double).

Is it some kind of index variable? For example, it's referring to a module labeled 2.5 in some specification or document? In that case I would not use any kind of floating-point type for it at all, but create a separate variable for the submodule number:

For example, module = 2 and subModule = 5.
 
Tapas Chand
Ranch Hand
Posts: 614
9
BSD Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this context module is something denoting the size of a switch(electric).

Let us say we have 3 types of switches.
1. 120x120 px
2. 120x240 px
3. 120x360 px
So these are 1 module, 2 and 3 module respectively.
And these values will be used to fit the switches properly in board.

Now we will going to have something like this
1. 120x120 px
2. 120X180 px
3. 120x240 px
So in this case, modules will be 1, 1.5 and 2.

Somewhere down the line 1.5 will be added to 1.5 or it will be multiplied with 1/2/3. So decimal place will never exceed beyond 1.

 
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That looks more like integer arithmetic to me.
 
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are dealing with discrete quantities I'd definitely recommend staying away from doubles or floats and sticking with integral types.

If you need to display the quantities with decimal places then you can do that, but the format you display does not have to match the format you store and process.
 
Tapas Chand
Ranch Hand
Posts: 614
9
BSD Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike. J. Thompson wrote:If you are dealing with discrete quantities I'd definitely recommend staying away from doubles or floats and sticking with integral types.

If you need to display the quantities with decimal places then you can do that, but the format you display does not have to match the format you store and process.

Thank you, I got your point.
And 1, 1.5, 2 ... These values are never displayed in front end.
These are stored in DB and are used for processing.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
…and what format are they in the database?

You can get nasty errors with floating‑point arithmetic. You have probably been around long enough that you can tell me how often this loop runs without having to run it:-Floating‑point values ending .5 or .25 etc can be represented as integers divided by a power of 2 so they can be exactly represented as doubles providing they are small. Any other fraction cannot be exactly represented as a double. You would have to use BigDecimal instead. I think in the database that is called a DECIMAL.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, your variable 'module' is essentially not really a number, but a label that indicates one of three possible types of switches.

You could use an enum for this instead of an int or a floating-point number. For example:

 
Tapas Chand
Ranch Hand
Posts: 614
9
BSD Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:You can get nasty errors with floating‑point arithmetic.

Thank you for reminding me old mistakes.
Yes, I had used double as currency in past and faced consequences.
I am sticking to BigDecimal after that.

Currently module is defined as INT(2) in MySQL.
It stores values 1, 2, 3, 4 and 5.
Now I am going to modify it to DECIMAL(2,1)
It will store values 0.5, 1, 1.5, 2, 2.5, 3, 4 and 5.
 
Campbell Ritchie
Marshal
Posts: 56600
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What format do you get the DECIMAL back from the ResultSet (or similar)? Does it come back as a BigDecimal?
 
Tapas Chand
Ranch Hand
Posts: 614
9
BSD Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:What format do you get the DECIMAL back from the ResultSet (or similar)? Does it come back as a BigDecimal?

Oh, this is the part to be modified.
Now we are getting int from ResultSet because in DB it is INT(2).
Once I will alter the table to make the column datatype DECIMAL(2,1), I will modify the ResultSet part to get BigDecimal and prior to that the POJO will be modified accordingly.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!