Derby
  1. Derby
  2. DERBY-6083

Update minimum/maximum floating-point values to align with DERBY-3398 fixes

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: 10.10.1.1
    • Component/s: Documentation
    • Labels:
      None

      Description

      The limits for floating-point values have changed as a result of DERBY-3398 and should be documented:

      Smallest DOUBLE: 4.9e-324 (aka Double.MIN_VALUE)
      Largest DOUBLE: 1.7976931348623157e+308 (aka Double.MAX_VALUE)
      Smallest positive DOUBLE: 2.2250738585072014E-308 (aka Double.MIN_NORMAL)
      Largest negative DOUBLE: -2.2250738585072014E-308
      Smallest REAL: 1.4e-45 (aka Float.MIN_VALUE)
      Largest REAL: 3.4028235e+38 (aka Float.MAX_VALUE)
      Smallest positive REAL: 1.17549435E-38 (aka Float.MIN_NORMAL)
      Largest negative REAL: -1.17549435E-38

      1. DERBY-6083-2.zip
        12 kB
        Kim Haase
      2. DERBY-6083-2.stat
        0.2 kB
        Kim Haase
      3. DERBY-6083-2.diff
        13 kB
        Kim Haase
      4. DERBY-6083.zip
        6 kB
        Kim Haase
      5. DERBY-6083.stat
        0.1 kB
        Kim Haase
      6. DERBY-6083.diff
        7 kB
        Kim Haase

        Issue Links

          Activity

          Hide
          Kim Haase added a comment -

          Closing, since changes have appeared in Latest Alpha Manuals.

          Show
          Kim Haase added a comment - Closing, since changes have appeared in Latest Alpha Manuals.
          Hide
          Kim Haase added a comment -

          Thanks, Dag!

          Committed patch DERBY-6083-2.diff to documentation trunk at revision 1449749.

          Show
          Kim Haase added a comment - Thanks, Dag! Committed patch DERBY-6083 -2.diff to documentation trunk at revision 1449749.
          Hide
          Dag H. Wanvik added a comment -

          Looks good, Kim, thanks! +1

          Show
          Dag H. Wanvik added a comment - Looks good, Kim, thanks! +1
          Hide
          Kim Haase added a comment -

          Thanks again, Dag, for the review. Attaching DERBY-6083-2.diff, DERBY-6083-2.stat, and DERBY-6083-2.zip, with changes to 6 files instead of 3:

          M src/ref/rreffuncatan.dita
          M src/ref/rrefsqlj14122.dita
          M src/ref/rrefnumericlimits.dita
          M src/ref/rreffuncasin.dita
          M src/ref/rrefsqlj20204.dita
          M src/ref/rrefsqljdoubleprecision.dita

          I found the zero problem in only two topics. I found that rrefsqlj20204.dita, the one additional topic with mentions of floating-point values needed some fixes (both substantive and formatting) when I tried rerunning the sample commands.

          Thanks!

          Show
          Kim Haase added a comment - Thanks again, Dag, for the review. Attaching DERBY-6083 -2.diff, DERBY-6083 -2.stat, and DERBY-6083 -2.zip, with changes to 6 files instead of 3: M src/ref/rreffuncatan.dita M src/ref/rrefsqlj14122.dita M src/ref/rrefnumericlimits.dita M src/ref/rreffuncasin.dita M src/ref/rrefsqlj20204.dita M src/ref/rrefsqljdoubleprecision.dita I found the zero problem in only two topics. I found that rrefsqlj20204.dita, the one additional topic with mentions of floating-point values needed some fixes (both substantive and formatting) when I tried rerunning the sample commands. Thanks!
          Hide
          Kim Haase added a comment -

          Thanks, Dag! Some more topics to fix! I'll file a revised patch.

          Show
          Kim Haase added a comment - Thanks, Dag! Some more topics to fix! I'll file a revised patch.
          Hide
          Dag H. Wanvik added a comment -

          Yes, we do, cf. test below:

          ij> values -0.0;
          1


          0.0

          1 row selected
          ij> values asin(-0.0);
          1
          ------------------------
          0.0

          It can also be seen in the code in NumberDataType#normalize

          {Real,Double}

          :

          // Normalize negative floats to be "positive" (can't detect easily
          // without using Float object because -0.0f = 0.0f)
          // DERBY-2447: It shouldn't matter whether we compare to 0.0d or -0.0d,
          // both should match negative zero, but comparing to 0.0d triggered
          // this JVM bug: http://bugs.sun.com/view_bug.do?bug_id=6833879
          if (fv == -0.0f)

          { fv = 0.0f; }

          So it would seem the docs are wrong here.

          Show
          Dag H. Wanvik added a comment - Yes, we do, cf. test below: ij> values -0.0; 1 0.0 1 row selected ij> values asin(-0.0); 1 ------------------------ 0.0 It can also be seen in the code in NumberDataType#normalize {Real,Double} : // Normalize negative floats to be "positive" (can't detect easily // without using Float object because -0.0f = 0.0f) // DERBY-2447 : It shouldn't matter whether we compare to 0.0d or -0.0d, // both should match negative zero, but comparing to 0.0d triggered // this JVM bug: http://bugs.sun.com/view_bug.do?bug_id=6833879 if (fv == -0.0f) { fv = 0.0f; } So it would seem the docs are wrong here.
          Hide
          Kim Haase added a comment -

          Thanks, Dag! I suppose the NaN/infinity/zero info should be added to both the REAL and DOUBLE PRECISION topics. I will fix the inconsistent "e"s too.

          Do we really normalize -0 to +0? See, for example, http://db.apache.org/derby/docs/10.9/ref/rreffuncasin.html.

          I have not actually looked beyond the obvious places for mentions of the f-p values but I probably should do some grepping just to be sure.

          Show
          Kim Haase added a comment - Thanks, Dag! I suppose the NaN/infinity/zero info should be added to both the REAL and DOUBLE PRECISION topics. I will fix the inconsistent "e"s too. Do we really normalize -0 to +0? See, for example, http://db.apache.org/derby/docs/10.9/ref/rreffuncasin.html . I have not actually looked beyond the obvious places for mentions of the f-p values but I probably should do some grepping just to be sure.
          Hide
          Dag H. Wanvik added a comment -

          One item: I am not sure if this has been discussed in out docs anywhere: Derby normalizes -0.0 to positive 0.0.
          Although it can be deduced from what we say, it may be helpful to point out that we throw an exception if we calculate or try to store NaN or +/- inifinity too (as defined by IEEE 754 and represented with named constants in Java, e.g. Double.NaN).

          Show
          Dag H. Wanvik added a comment - One item: I am not sure if this has been discussed in out docs anywhere: Derby normalizes -0.0 to positive 0.0. Although it can be deduced from what we say, it may be helpful to point out that we throw an exception if we calculate or try to store NaN or +/- inifinity too (as defined by IEEE 754 and represented with named constants in Java, e.g. Double.NaN).
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Kim! No, the precisions are not changed so the FLOAT section is fine as is. +1 to changing the language on "smallest"; I used the same in the code. Nit: in the table in rrefnumericlimits.dita the exponents "e" are given with varying case.
          As for further changes, I haven't gone through all the manuals to look for occurrences of the limits, but I imagine you did
          If so, +1 to the patch!

          Show
          Dag H. Wanvik added a comment - Thanks, Kim! No, the precisions are not changed so the FLOAT section is fine as is. +1 to changing the language on "smallest"; I used the same in the code. Nit: in the table in rrefnumericlimits.dita the exponents "e" are given with varying case. As for further changes, I haven't gone through all the manuals to look for occurrences of the limits, but I imagine you did If so, +1 to the patch!
          Hide
          Kim Haase added a comment -

          Attaching DERBY-6083.diff, DERBY-6083.stat, and DERBY-6083.zip, with changes as follows:

          M src/ref/rrefsqlj14122.dita
          M src/ref/rrefsqljdoubleprecision.dita
          M src/ref/rrefnumericlimits.dita

          I redefined "smallest" and "largest" in addition to providing the new values. I also changed the sentence after each list in the data type topics.

          Please let me know what changes are needed. I was also wondering about the topic on the FLOAT data type – I am guessing the precisions are the same so no changes are needed here?

          Thanks very much.

          Show
          Kim Haase added a comment - Attaching DERBY-6083 .diff, DERBY-6083 .stat, and DERBY-6083 .zip, with changes as follows: M src/ref/rrefsqlj14122.dita M src/ref/rrefsqljdoubleprecision.dita M src/ref/rrefnumericlimits.dita I redefined "smallest" and "largest" in addition to providing the new values. I also changed the sentence after each list in the data type topics. Please let me know what changes are needed. I was also wondering about the topic on the FLOAT data type – I am guessing the precisions are the same so no changes are needed here? Thanks very much.
          Hide
          Kim Haase added a comment -

          Thanks for the info about the values, Knut.

          The terms "smallest" and "largest" seem to have been used in our documentation to refer to positions on a number line, where "smallest" means "farthest to the left" and "largest" means "farthest to the right". So we have been saying that the "Smallest DOUBLE" was -1.79769E+308, while the "Largest DOUBLE" was the positive version of that, 1.79769E+308. Similarly, we called -2.225E-307 the "Largest negative DOUBLE" because it's closest to zero.

          This is confusing because we (I, anyway?) usually think of "smallest" and "largest" as referring to magnitude, as defined by whether the exponent is negative or positive. So the closer a number is to zero the smaller it is, whether negative or positive. The Java API docs for java.lang.Double and java.lang.Float use this terminology. I think I'll try to get closer to the language used there. This will involve using the terms "normalized" and "denormalized", but I don't think that's a major issue.

          Show
          Kim Haase added a comment - Thanks for the info about the values, Knut. The terms "smallest" and "largest" seem to have been used in our documentation to refer to positions on a number line, where "smallest" means "farthest to the left" and "largest" means "farthest to the right". So we have been saying that the "Smallest DOUBLE" was -1.79769E+308, while the "Largest DOUBLE" was the positive version of that, 1.79769E+308. Similarly, we called -2.225E-307 the "Largest negative DOUBLE" because it's closest to zero. This is confusing because we (I, anyway?) usually think of "smallest" and "largest" as referring to magnitude, as defined by whether the exponent is negative or positive. So the closer a number is to zero the smaller it is, whether negative or positive. The Java API docs for java.lang.Double and java.lang.Float use this terminology. I think I'll try to get closer to the language used there. This will involve using the terms "normalized" and "denormalized", but I don't think that's a major issue.

            People

            • Assignee:
              Kim Haase
              Reporter:
              Kim Haase
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development