Bigdecimal problem

Discussion in 'Java' started by manzur, Jun 6, 2006.

  1. manzur

    manzur Guest

    BigDecimal bigDecimal = new BigDecimal("1.00");
    BigDecimal bigDecima2 = new BigDecimal("1");

    System.out.println(bigDecimal.equals(bigDecima2));

    The above gives me false.

    Wht should i do to make it print true with out disturbing my already
    created bigdecimals.
    Bcoz i feel that 1.0,1.00,1,1.0000 are same


    thanks in advance
     
    manzur, Jun 6, 2006
    #1
    1. Advertising

  2. manzur

    Oliver Wong Guest

    "manzur" <> wrote in message
    news:...
    > BigDecimal bigDecimal = new BigDecimal("1.00");
    > BigDecimal bigDecima2 = new BigDecimal("1");
    >
    > System.out.println(bigDecimal.equals(bigDecima2));
    >
    > The above gives me false.
    >
    > Wht should i do to make it print true with out disturbing my already
    > created bigdecimals.
    > Bcoz i feel that 1.0,1.00,1,1.0000 are same


    Read the JavaDocs for BigDecimal:
    http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html

    They explicitly tell you that equals will return false when comparing
    2.0 to 2.00. They also explain how to get the results you want.

    Why would the behaviour of 2.0 != 2.00 be useful? Perhaps for
    scientific/engineering applications where significant digits are meaningful.

    - Oliver
     
    Oliver Wong, Jun 6, 2006
    #2
    1. Advertising

  3. manzur

    manzur Guest

    Re: Bigdecimal problem

    Oliver Wong wrote:
    > "manzur" <> wrote in message
    > news:...
    > > BigDecimal bigDecimal = new BigDecimal("1.00");
    > > BigDecimal bigDecima2 = new BigDecimal("1");
    > >
    > > System.out.println(bigDecimal.equals(bigDecima2));
    > >
    > > The above gives me false.
    > >
    > > Wht should i do to make it print true with out disturbing my already
    > > created bigdecimals.
    > > Bcoz i feel that 1.0,1.00,1,1.0000 are same

    >
    > Read the JavaDocs for BigDecimal:
    > http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html
    >
    > They explicitly tell you that equals will return false when comparing
    > 2.0 to 2.00. They also explain how to get the results you want.
    >
    > Why would the behaviour of 2.0 != 2.00 be useful? Perhaps for
    > scientific/engineering applications where significant digits are meaningful.
    >
    > - Oliver



    iam developing some banking applications where i need to show that 1.0
    ,1.00,1.000 are same
     
    manzur, Jun 6, 2006
    #3
  4. manzur

    jhr Guest

    Re: Bigdecimal problem

    manzur wrote:
    > Oliver Wong wrote:
    > > "manzur" <> wrote in message
    > > news:...
    > > > BigDecimal bigDecimal = new BigDecimal("1.00");
    > > > BigDecimal bigDecima2 = new BigDecimal("1");
    > > >
    > > > System.out.println(bigDecimal.equals(bigDecima2));
    > > >
    > > > The above gives me false.
    > > >
    > > > Wht should i do to make it print true with out disturbing my already
    > > > created bigdecimals.
    > > > Bcoz i feel that 1.0,1.00,1,1.0000 are same

    > >
    > > Read the JavaDocs for BigDecimal:
    > > http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html
    > >
    > > They explicitly tell you that equals will return false when comparing
    > > 2.0 to 2.00. They also explain how to get the results you want.
    > >
    > > Why would the behaviour of 2.0 != 2.00 be useful? Perhaps for
    > > scientific/engineering applications where significant digits are meaningful.
    > >
    > > - Oliver

    >
    >
    > iam developing some banking applications where i need to show that 1.0
    > ,1.00,1.000 are same


    Try:

    if (bigDecimal.compareTo(bigDecima2) == 0)
    {
    // code for equals == true
    }
     
    jhr, Jun 6, 2006
    #4
  5. Oliver Wong wrote:
    > "manzur" <> wrote in message
    > news:...
    >> BigDecimal bigDecimal = new BigDecimal("1.00");
    >> BigDecimal bigDecima2 = new BigDecimal("1");
    >>
    >> System.out.println(bigDecimal.equals(bigDecima2));
    >>
    >> The above gives me false.
    >>
    >> Wht should i do to make it print true with out disturbing my already
    >> created bigdecimals.
    >> Bcoz i feel that 1.0,1.00,1,1.0000 are same

    >
    > Read the JavaDocs for BigDecimal:
    > http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html
    >
    > They explicitly tell you that equals will return false when comparing
    > 2.0 to 2.00. They also explain how to get the results you want.
    >
    > Why would the behaviour of 2.0 != 2.00 be useful? Perhaps for
    > scientific/engineering applications where significant digits are
    > meaningful.
    >
    > - Oliver


    At a more basic level, the result of some operations involving a
    BigDecimal depend on its scale. toString gives different answers. The
    precision is different. Rounded divisions give different answers.

    They are just not equivalent objects.

    Patricia
     
    Patricia Shanahan, Jun 6, 2006
    #5
  6. Hi,

    Patricia Shanahan wrote:
    >>> BigDecimal bigDecimal = new BigDecimal("1.00");
    >>> BigDecimal bigDecima2 = new BigDecimal("1");
    >>>
    >>> System.out.println(bigDecimal.equals(bigDecima2));
    >>>

    >
    > At a more basic level, the result of some operations involving a
    > BigDecimal depend on its scale. toString gives different answers. The
    > precision is different. Rounded divisions give different answers.


    I understand that, but I think that is not a reason that "1.0" and
    "1.00" should not be equal. I mean, especially...

    > They are just not equivalent objects.


    ....that is (IMHO) not correct: "equivalent" - the same word as in
    Germany (although we use the strange "Umlaut" "ä" at the beginning) -
    which (AFAIK) comes from the Latin words for "equal" and "value", and I
    think, the values of "1.00" and "1.0" *are* the same.

    Ciao,
    Ingo
     
    Ingo R. Homann, Jun 7, 2006
    #6
  7. manzur

    Oliver Wong Guest

    "Ingo R. Homann" <> wrote in message
    news:4486c9a7$0$11077$-online.net...
    > Hi,
    >
    > Patricia Shanahan wrote:
    >>>> BigDecimal bigDecimal = new BigDecimal("1.00");
    >>>> BigDecimal bigDecima2 = new BigDecimal("1");
    >>>>
    >>>> System.out.println(bigDecimal.equals(bigDecima2));
    >>>>

    >>
    >> At a more basic level, the result of some operations involving a
    >> BigDecimal depend on its scale. toString gives different answers. The
    >> precision is different. Rounded divisions give different answers.

    >
    > I understand that, but I think that is not a reason that "1.0" and "1.00"
    > should not be equal. I mean, especially...
    >
    >> They are just not equivalent objects.

    >
    > ...that is (IMHO) not correct: "equivalent" - the same word as in Germany
    > (although we use the strange "Umlaut" "ä" at the beginning) - which
    > (AFAIK) comes from the Latin words for "equal" and "value", and I think,
    > the values of "1.00" and "1.0" *are* the same.


    As I've mentioned elsewhere in this newsgroup (but not within this
    thread), the concept of equality is context dependent. Are "1.00" and "1.0"
    equal? Perhaps yes, if you're talking about pure mathematical numbers.
    Perhaps no, if you're talking about engineering measurements with specific
    tolerance levels [*]. Definitely not, if you're talking about Strings.

    The Java API was designed so that you could provide a comparator object,
    so that you could using different metrics for determining how two objects
    compare, depending on which metric you're interested in. I thought it might
    be a good idea if they did the same thing for the equals method (so you
    could provide a custom object to determine whether two objects are equal,
    depending on the context). Unfortunately, the API wasn't designed that way.

    But moving away from idle daydreaming and coming back to practical
    matters: recall that in Java, you're free to implement the equals() method
    any way you want, as long as some basic requirements (reflexivity,
    transitivity, etc.) are met. The people who designed the BigDecimal class
    decided to design it in that particular way. Anyway, it's not like you can't
    get the above mentioned desired behaviour: All you have to do is use
    compareTo().

    - Oliver

    [*] An engineer might reject a part that measures "1.0 mm", requiring one
    that measures "1.00 mm". Why? Because that engineer might know that if the
    part actually measures 1.01 mm (which is considered to be a "1.0 mm" part,
    but not a "1.00 mm" part), the device will fail and/or break, whereas if the
    device measures 1.004 mm (which is both a "1.0 mm" and "1.00 mm" part), the
    device will tolerate this small deviancy, and continue functioning.
     
    Oliver Wong, Jun 7, 2006
    #7
  8. Ingo R. Homann wrote:
    > Hi,
    >
    > Patricia Shanahan wrote:
    >>>> BigDecimal bigDecimal = new BigDecimal("1.00");
    >>>> BigDecimal bigDecima2 = new BigDecimal("1");
    >>>>
    >>>> System.out.println(bigDecimal.equals(bigDecima2));
    >>>>

    >>
    >> At a more basic level, the result of some operations involving a
    >> BigDecimal depend on its scale. toString gives different answers. The
    >> precision is different. Rounded divisions give different answers.

    >
    > I understand that, but I think that is not a reason that "1.0" and
    > "1.00" should not be equal. I mean, especially...
    >
    >> They are just not equivalent objects.

    >
    > ...that is (IMHO) not correct: "equivalent" - the same word as in
    > Germany (although we use the strange "Umlaut" "ä" at the beginning) -
    > which (AFAIK) comes from the Latin words for "equal" and "value", and I
    > think, the values of "1.00" and "1.0" *are* the same.
    >
    > Ciao,
    > Ingo
    >


    Anyone who thinks they are equivalent objects, try running this:

    import java.math.BigDecimal;
    public class TestBigDecimal {
    public static void main(String[] args) {
    System.out.println(new BigDecimal("1.0").
    divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    System.out.println(new BigDecimal("1.00").
    divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    }
    }

    If they really were equivalent, I would expect them to do the same for
    anything other than the identity related operations, == comparison and
    System.identityHashCode().

    A BigDecimal has both a decimal value and a scale, not just a decimal
    value. The scale affects some operations, such as the rounded divisions
    in the example program.

    Their decimal values are equal, and decimal value is the natural
    ordering, so it makes sense for compareTo to treat them as equal.

    Patricia
     
    Patricia Shanahan, Jun 7, 2006
    #8
  9. Ingo R. Homann wrote:
    > I
    > think, the values of "1.00" and "1.0" *are* the same.


    Not if you are an engineer. 1.00 indicates a higher precision than 1.0.
    Depending on the type of rounding used (AFAIK varies in different
    countries in engineering), the above numbers e.g. indicate the two
    different ranges

    1.00: [0.995, 1.005)
    1.0: [0.95, 1.05)

    for an engineer. And these ranges are rather different.

    Stichwort "Signifikante Stellen"

    /Thomas
    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, Jun 7, 2006
    #9
  10. Hi,

    Oliver Wong wrote:
    >>>>> BigDecimal bigDecimal = new BigDecimal("1.00");
    >>>>> BigDecimal bigDecima2 = new BigDecimal("1");
    >>>>>
    >>>>> System.out.println(bigDecimal.equals(bigDecima2));

    > ...
    > As I've mentioned elsewhere in this newsgroup (but not within this
    > thread), the concept of equality is context dependent. Are "1.00" and
    > "1.0" equal? Perhaps yes, if you're talking about pure mathematical
    > numbers. Perhaps no, if you're talking about engineering measurements
    > with specific tolerance levels


    Ah, OK, that is a point I did not consider! I was only thinking of the
    "mathematical" equality.

    Still, I am not convinced that the two values should not be mathematical
    equal (which you did not say), but I see (and agree to) your point, and
    it might be enough to say "they are not *generally* equal".

    I know that compareTo() does exactly what I want, but I just think,
    "b.compareTo(BigDecimal.ZERO)==0" is not as beautiful and readable as
    "b.equals(BigDecimal.ZERO)" or even (if operator overloading would be
    allowed) "b==BigDecimal.ZERO" (or perhaps "b===BigDecimal.ZERO", if you
    think that is is not a good idea to allow to overload the
    "referential-equality-comparison-operator" ==).

    Ciao,
    Ingo, daydreaming ;-)
     
    Ingo R. Homann, Jun 7, 2006
    #10
  11. Hi,

    Patricia Shanahan wrote:
    > Anyone who thinks they are equivalent objects, try running this:
    >
    > import java.math.BigDecimal;
    > public class TestBigDecimal {
    > public static void main(String[] args) {
    > System.out.println(new BigDecimal("1.0").
    > divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    > System.out.println(new BigDecimal("1.00").
    > divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    > }
    > }
    >
    > If they really were equivalent, I would expect them to do the same for
    > anything other than the identity related operations, == comparison and
    > System.identityHashCode().


    OK, that's perfectly right. But perhaps, only the specification of the
    method divide() is not consistent. Perhaps it would have been better if
    you would have been forced to explicitely name the scale of the result:

    BigDecimal devide(BigDecimal d, RoundingMode r, scale s) {...}

    So, I am not convinced that equals is implemented/specified
    mathematically correct.

    Or am I missing something?

    Ciao,
    Ingo
     
    Ingo R. Homann, Jun 8, 2006
    #11
  12. Ingo R. Homann wrote:
    > Hi,
    >
    > Patricia Shanahan wrote:
    >> Anyone who thinks they are equivalent objects, try running this:
    >>
    >> import java.math.BigDecimal;
    >> public class TestBigDecimal {
    >> public static void main(String[] args) {
    >> System.out.println(new BigDecimal("1.0").
    >> divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    >> System.out.println(new BigDecimal("1.00").
    >> divide(new BigDecimal(3),BigDecimal.ROUND_HALF_EVEN));
    >> }
    >> }
    >>
    >> If they really were equivalent, I would expect them to do the same for
    >> anything other than the identity related operations, == comparison and
    >> System.identityHashCode().

    >
    > OK, that's perfectly right. But perhaps, only the specification of the
    > method divide() is not consistent. Perhaps it would have been better if
    > you would have been forced to explicitely name the scale of the result:
    >
    > BigDecimal devide(BigDecimal d, RoundingMode r, scale s) {...}
    >
    > So, I am not convinced that equals is implemented/specified
    > mathematically correct.
    >
    > Or am I missing something?


    You may be missing something that people have been missing, at times,
    for at least 50 years.

    The original Fortran type for floating point was called "REAL".
    Unfortunately, this encouraged programmers to think of its arithmetic as
    real arithmetic, instead of floating point arithmetic. Sometimes, that
    got them into trouble because floating point arithmetic differs from
    real arithmetic in some critical properties. For example, real addition
    is always associative, floating point addition isn't.

    You are confusing BigDecimal arithmetic with decimal fraction
    arithmetic, and don't like it they turn out to be different, essentially
    the same problem as confusing floating point and real arithmetic, and
    being disturbed whenever (a+b)+c is different from a+(b+c).

    If a BigDecimal were simply a decimal fraction, you would be right about
    1.0 == 1.00, and the number would not have a scale attribute, so no
    operation results would depend on scale.

    A BigDecimal is not just a decimal fraction. BigDecimal is a different,
    equally valid, system of arithmetic in which each number has a scale,
    and results of arithmetic operations can depend on the scale. The scale
    is a guide to the intended precision of the calculation, so it makes
    sense to have options to round according to the current scale.

    It is not a matter of "mathematically correct" because mathematics, no
    matter how much it has to say about decimal fraction arithmetic, says
    nothing about java.math.BigDecimal arithmetic. It is a matter of
    defining an arithmetic system that is useful for certain purposes.

    Of course, to some extent BigDecimal is a model of decimal fraction
    arithmetic, but it has its own rules, designed to be useful in a range
    of contexts.

    Patricia
     
    Patricia Shanahan, Jun 8, 2006
    #12
  13. manzur

    Chris Uppal Guest

    Patricia Shanahan wrote:

    > It is not a matter of "mathematically correct" because mathematics, no
    > matter how much it has to say about decimal fraction arithmetic, says
    > nothing about java.math.BigDecimal arithmetic. It is a matter of
    > defining an arithmetic system that is useful for certain purposes.
    >
    > Of course, to some extent BigDecimal is a model of decimal fraction
    > arithmetic, but it has its own rules, designed to be useful in a range
    > of contexts.


    And one could also define an EvenBiggerDecimal class with instances that had no
    scale (or, equivalently, whose scale was always unbounded). In that case they
    would, up to the limits of available time and memory, correspond exactly to the
    mathematical (finite) decimal fractions.

    Maybe the problem here is that BigDecimal is misnamed; it would be better
    called something like ScaledDecimal.

    In a way there's a connection here with numbers used to represent quantities.
    One pound does not equal one kilogram, even though they both are represented as
    1. In a similar kind of way, 1.00 is not the same as 1.0 since they represent
    amounts of different things -- in one case the number of hundredths, in the
    other the number of tenths.

    -- chris
     
    Chris Uppal, Jun 8, 2006
    #13
  14. manzur

    Dale King Guest

    Oliver Wong wrote:
    >
    > [*] An engineer might reject a part that measures "1.0 mm", requiring
    > one that measures "1.00 mm". Why? Because that engineer might know that
    > if the part actually measures 1.01 mm (which is considered to be a "1.0
    > mm" part, but not a "1.00 mm" part), the device will fail and/or break,
    > whereas if the device measures 1.004 mm (which is both a "1.0 mm" and
    > "1.00 mm" part), the device will tolerate this small deviancy, and
    > continue functioning.


    I remember in a freshman engineering course the teacher (who came from
    industry) told us about a time they were given drawings to make these
    large metal disks with these holes in them and the drawing specified the
    holes to be 6.000 inches in diameter. They went to a lot of work to get
    them to those tolerances. When they got them done they found out that
    they were use within a large pipe to slow down the flow. So in reality
    they could have been +/- inches.
    --
    Dale King
     
    Dale King, Jun 11, 2006
    #14
  15. manzur

    rajends1

    Joined:
    Aug 7, 2012
    Messages:
    1
    try doublevalue

    please try doublevalue like below

    BigDecimal a = new BigDecimal("0.00");
    BigDecimal b = new BigDecimal("0.0");
    BigDecimal c = new BigDecimal("0");

    if(a.doubleValue()==BigDecimal.ZERO.doubleValue()){
    System.out.println("a equals");
    }

    if(b.doubleValue()==BigDecimal.ZERO.doubleValue()){
    System.out.println("b equals");
    }

    if(c.doubleValue()==BigDecimal.ZERO.doubleValue()){
    System.out.println("c equals");
    }
     
    rajends1, Aug 7, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Forrest Hump
    Replies:
    4
    Views:
    24,285
    Mark Meyer
    Aug 22, 2003
  2. davo_java
    Replies:
    1
    Views:
    751
    davo_java
    Jun 23, 2005
  3. manzur

    Bigdecimal division problem

    manzur, Feb 23, 2006, in forum: Java
    Replies:
    5
    Views:
    8,137
    Patricia Shanahan
    Feb 23, 2006
  4. Replies:
    3
    Views:
    1,233
  5. Stanimir Stamenkov
    Replies:
    4
    Views:
    2,591
    Stanimir Stamenkov
    Jul 18, 2008
Loading...

Share This Page