groovy
  1. groovy
  2. GROOVY-339

Problem coercing 7/3 to double

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0-beta-5
    • Fix Version/s: 1.0-beta-5
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      2

      Description

      1> println( Math.sin(7/3) )
      2> go
      No such method: sin for class: java.lang.Math with arguments: [2.3333333333]

      1> println( Math.sin(2.3333333333) )
      2> go
      0.7230858817613498

      1. method_not_found.patch
        3 kB
        Brian Larson
      2. GroovyBDtoDoubleCoerce.patch
        6 kB
        Brian Larson

        Issue Links

          Activity

          Hide
          Rod Cope added a comment -

          Workaround:

          println( Math.sin( (7/3).doubleValue() ) )

          Show
          Rod Cope added a comment - Workaround: println( Math.sin( (7/3).doubleValue() ) )
          Hide
          Brian Larson added a comment -

          This is by design. Division produces a Double result if either operand is either Float or Double and a BigDecimal result otherwise. See http://groovy.codehaus.org/math.html. This is to prevent unexpected results which occur with binary floating point types in arithmetic (e.g. .1F + 1.1F does not equal 1.2F)

          The "workaround" is the correct syntax.

          However, the error message should be improved to indicate the method signature.

          The attached patch improves the message.

          In the example above, with the patch applied, the message is:
          No such method: sin(java.math.BigDecimal) for class: java.lang.Math with arguments: [2.3333333333]

          Show
          Brian Larson added a comment - This is by design. Division produces a Double result if either operand is either Float or Double and a BigDecimal result otherwise. See http://groovy.codehaus.org/math.html . This is to prevent unexpected results which occur with binary floating point types in arithmetic (e.g. .1F + 1.1F does not equal 1.2F) The "workaround" is the correct syntax. However, the error message should be improved to indicate the method signature. The attached patch improves the message. In the example above, with the patch applied, the message is: No such method: sin(java.math.BigDecimal) for class: java.lang.Math with arguments: [2.3333333333]
          Hide
          Rod Cope added a comment -

          Okay, so the "right" way to do it would be:

          println( Math.sin( 7.0 / 3.0 ) )

          Thanks.

          Show
          Rod Cope added a comment - Okay, so the "right" way to do it would be: println( Math.sin( 7.0 / 3.0 ) ) Thanks.
          Hide
          Brian Larson added a comment -

          No. This may work with the current code, but numeric literals with a decimal point are supposed to be BigDecimal by default. This code is included in the parser rework which will be committed soon. See issue 256. Also, the updated wiki is in the patch for issue 256.

          So, if you want to do something like that, you need to use the numeric literal suffixes, like:

          println( Math.sin( 7.0D / 3.0D ) )

          Actually, if either 7.0 or 3.0 is suffixed with D, the result will be a Double.

          Show
          Brian Larson added a comment - No. This may work with the current code, but numeric literals with a decimal point are supposed to be BigDecimal by default. This code is included in the parser rework which will be committed soon. See issue 256. Also, the updated wiki is in the patch for issue 256. So, if you want to do something like that, you need to use the numeric literal suffixes, like: println( Math.sin( 7.0D / 3.0D ) ) Actually, if either 7.0 or 3.0 is suffixed with D, the result will be a Double.
          Hide
          Chris Poirier added a comment -

          As discussed elsewhere, we should do auto-coercion of BigDecimal to Double, with an exception thrown when the BigDecimal is too big. This seems as good a place as any for the work.

          Show
          Chris Poirier added a comment - As discussed elsewhere, we should do auto-coercion of BigDecimal to Double, with an exception thrown when the BigDecimal is too big. This seems as good a place as any for the work.
          Hide
          Brian Larson added a comment -

          Ok. I'll start looking into it.

          Show
          Brian Larson added a comment - Ok. I'll start looking into it.
          Hide
          Brian Larson added a comment -

          Here is the patch to permit "safe" BigDecimal to Double coercion as discussed in issue 256, for example, Math.sin(7.3). I'd like to get this into CVS before we release the next beta (beta 5?) if possible. Some other coersion issues will be covered in issue GROOVY-275.

          Show
          Brian Larson added a comment - Here is the patch to permit "safe" BigDecimal to Double coercion as discussed in issue 256, for example, Math.sin(7.3). I'd like to get this into CVS before we release the next beta (beta 5?) if possible. Some other coersion issues will be covered in issue GROOVY-275 .
          Hide
          Brian Larson added a comment -

          bump now that the cvs mailing list seems to be working. Please apply the patches when you get a chance.

          Show
          Brian Larson added a comment - bump now that the cvs mailing list seems to be working. Please apply the patches when you get a chance.
          Hide
          Steve Goetze added a comment -

          Applied patch

          Show
          Steve Goetze added a comment - Applied patch

            People

            • Assignee:
              Brian Larson
              Reporter:
              Rod Cope
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: