[Octave-bug-tracker] [bug #36133] num2str fails to switch from integer output to exponential notation for large values

[Dan Sebald]

Follow-up Comment #16, bug #36133 (project octave):

That was easy, good.

I wonder if there should be a test to check the IEEE 754 rule I listed below
regarding the conversion to a string and back from a string.  (Comparing
against an actual string might already achieve this.)  That is, there should
be some mode in which printing out the numbers and then bringing them back
into Octave results in the exact same internal representation.  Here's an
example:


>> a = 12345678901234567890
a =    1.2346e+19
>> astr = num2str(a)
astr = 1.234567890123457e+19
>> eval(['b = ' astr])
b =    1.2346e+19
>> a == b
ans = 0


Note how b no longer equals a.  If someone were to save their data into a file
using num2str in order to make is "portable", s/he might not be happy about
the above fact.

The minor capping change from 16 to 17 digits fixes this.  I tried the
following:


diff --git a/scripts/general/num2str.m b/scripts/general/num2str.m
--- a/scripts/general/num2str.m
+++ b/scripts/general/num2str.m
@@ -107,7 +107,7 @@ function retval = num2str (x, arg)
         if (ndgt > 15 || any (x(valid) != fix (x(valid))))
           ## Floating point input
           ndgt = max (ndgt + 5, 5);   # Keep at least 5 significant digits
-          ndgt = min (ndgt, 16);      # Cap significant digits at 16
+          ndgt = min (ndgt, 17);      # Cap significant digits at 16
           fmt = sprintf ("%%%d.%dg", ndgt+7, ndgt);
         else
           ## Integer input


and the test above passes:


>> astr = num2str(a)
astr = 1.2345678901234567e+19
>> eval(['b = ' astr])
b =    1.2346e+19
>> a == b
ans = 1


Note the extra digit of resolution.

Is there something to take into account that the number of digits resolution
can vary from 15-17?  Is "shimming" still needed when the number of valid
resolution digits is 15 for IEEE 754 when typically we'd want to ensure 17
digit resolution can be addressed?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36133>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/