bugGNU Octave - Bugs: bug #53166, format long displays 15...

 
 

bug #53166: format long displays 15 significant digits, rather than 15 digits after decimal point (Matlab Compatibility)

Submitter:  Rik <rik5>
Submitted:  Fri 16 Feb 2018 01:05:16 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 23 Feb 2018 04:30:54 AM UTC, comment #9: 

I think this is a good improvement.  I'm marking bug as fixed and closing it.

Rik <rik5>
Group administrator
Thu 22 Feb 2018 07:49:02 PM UTC, comment #8: 

Ignoring for a moment whether 15 or 16 digits is correct, here is what Octave will try to do now, using double precision values for example.  With format short (the default), Octave will try to display at least 5 significant figures, with 5 digits after the decimal and will allow the decimal position to float.  The maximum number of significant digits displayed is currently 16 (maybe it should be 15, but that's a separate issue).  If that point is reached, the display switches to E format.  There is also a maximum field width.  If that is exceeded (say, by attempting to display a small fraction as 0.0000...NNNN) then the display switches to E format.  For arrays, you can get results like this:


octave> n = 5; (logspace (-n, n, 2*n+1) * 1.2345678901234567890)'
ans =

        0.000012346
        0.000123457
        0.001234568
        0.012345679
        0.123456789
        1.234567890
       12.345678901
      123.456789012
     1234.567890123
    12345.678901235
   123456.789012346


Changing N to 6 in the expression above will give you short E format:


octave> n = 6; (logspace (-n, n, 2*n+1) * 1.2345678901234567890)'
ans =

   1.2346e-06
   1.2346e-05
   1.2346e-04
   1.2346e-03
   1.2346e-02
   1.2346e-01
   1.2346e+00
   1.2346e+01
   1.2346e+02
   1.2346e+03
   1.2346e+04
   1.2346e+05
   1.2346e+06


This seems quite reasonable to me.

If you prefer fixed format more like what Matlab provides, then you can use "fixed_point_format (true)" and Octave will show you something like this:


octave> fixed_point_format (true); n = 5; (logspace (-n, n, 2*n+1) * 1.2345678901234567890)'
ans =

  1.0e+05 *

   0.00000
   0.00000
   0.00000
   0.00000
   0.00000
   0.00001
   0.00012
   0.00123
   0.01235
   0.12346
   1.23457


I believe this is (approximately) what Matlab does by default.  I find it less useful in most cases than allowing the decimal position to float.

For scalar values, the rules are the same, but not as evident.  Instead of what Matlab is doing, Octave will show you this:


octave> format long, pi, 10*pi, 100*pi
ans =  3.141592653589793
ans =  31.41592653589793
ans =  314.1592653589793


With fixed format, the results are similar.

With scalar values, I just noticed a small problem when writing this comment.  Octave doesn't properly switch to E format when the number of digits to be displayed exceeds the number of digits of precision available for the given data type.  So it will do things like this:


format long, pi, 1e19*pi, 1e20*pi
ans =  3.141592653589793
ans =  31415926535897931776
ans =    3.141592653589793e+20


I'll take a look at fixing that now.

John W. Eaton <jwe>
Group administrator
Thu 22 Feb 2018 06:44:54 PM UTC, comment #7: 


Matlab r2018a prerelease

>> pi*10
ans =
   31.4159
>> format long
>> pi*10
ans =
  31.415926535897931


Philip Nienhuis <philipnienhuis>
Group Member
Thu 22 Feb 2018 10:41:46 AM UTC, comment #6: 

No, that's not what I meant. What does Matlab print when with format long you display just the single values pi* 10 or pi* 100, all by themselves? Octave displays always 15 digits. One could argue that Octave could also display 16 digits (I am not in favour of this, as it can pretend to have accuracy that is not there). However, Matlab according to its documentation at https://de.mathworks.com/help/matlab/ref/format.html gives you "fixed-decimal format with 15 digits after the decimal point for double values". Therefore, pi has one digit before the decimal point, giving you 16 digits overall, but pi*10 has two digits before the decimal point, giving you 17 digits and so on. Of course this would be nonsense (therefore my claim that this is either a Matlab bug or a Matlab documentation bug) UNLESS Matlab changes over to %e (in printf terminology) for all non-integer values >=10, because then there is always just one digit before the decimal point. So please somebody try what Matlab gives for


pi*10


Michael Leitner <mleitner>
Fri 16 Feb 2018 05:02:03 PM UTC, comment #5: 

I asked for a test of Matlab on the Maintainer's list:

Matlab:


 format long
 x = pi;
 y = [x; x*10; x*100; x*1000]
 single (y)

y =

   1.0e+03 *

   0.003141592653590
   0.031415926535898
   0.314159265358979
   3.141592653589793


ans =

  4×1 single column vector

   1.0e+03 *

   0.0031416
   0.0314159
   0.3141593
   3.1415928


In Octave, for the last value


format long
fixed_point_format (true)
x = pi;
y = [x; x*10; x*100; x*1000]
y =

  1.0e+03 *

   0.003141592653590
   0.031415926535898
   0.314159265358979
   3.141592653589793


When configured with exactly the same options, Matlab and Octave are equivalent.  If I disable fixed_point_format the results are


fixed_point_format (false)
y
y =

      3.14159265358979
     31.41592653589793
    314.15926535897933
   3141.59265358979292


The Matlab equivalent display for pi has one extra digit on it as mentioned earlier:

Matlab


format long
3.141592653589793


In general, the IEEE-854 double precision format has 15-17 significant digits (https://en.wikipedia.org/wiki/Double-precision_floating-point_format).  A reasonable argument can be made that Octave should be showing the "average" case of 16 significant digits (rather than 15 which is what we do now).  This would imply that we increase by 1 the number of digits we show in the "format long" case.



Rik <rik5>
Group administrator
Fri 16 Feb 2018 09:49:42 AM UTC, comment #4: 

I'm sorry, probably I just let myself be bitten by this floating-point business. Probably 0.9 has a floating-point representation that it just a bit larger than 0.9 and thus gives rises to this seemingly incorrect rounding. But the rest of my comment of course stands.

Michael Leitner <mleitner>
Fri 16 Feb 2018 09:32:35 AM UTC, comment #3: 

That has to be either a Matlab bug or a Matlab documentation bug (I just looked it up, the really talk about "after the decimal point"). Does that mean that Matlab would print a 26-digit output for the following code, or do they immediately switch to scientific notation for values larger or equal to 10?


format long
pi*10000000000


There is perhaps some very small Octave documentation inaccuracy in terms of how "significant figures" are defined. Consider


1+2^-52
1-2^-52


Note that in the second case 15 zeros are printed, in contrast to only 14 in the first case. This is because 1-2^-52 is actually 0.9999..., so the first significant figure is the one after the decimal point, while it is before the point for 1+2^-52. With rounding, both numbers look equal, so this distinction is lost. But I see no reason to change the behaviour or to reword the documentation to reflect that.

But I think that Octave could do better (perhaps that is what Matlab actually does without being clear about it), in the sense of "format long" implying to output as much information as possible, that is as much figures as possible, without ever faking information. eps(1)=2.2e-16, therefore in the range [1,2) you can find for every fixed-point number with 15 digits after the decimal point an IEEE 754-double that if rounded to those 15 digits gives exactly this fixed-point number. In the range [2,4) your discretization is 4.4e-16, and for [4,8) 8.8e-16. That is, if you print in this range 15 digits after the point, you do not pretend any information that is not there (and this covers the case of pi). Only for [8,10) you have a discretization of 1.8e-15, that is, here there are some fixed-point numbers that you cannot represent as rounded doubles, so you should print only 14 figures after the point (that is, the present choice of 15 significant figures overall).

By the way, during testing I found the following on my 4.0.3 Octave:


/tmp:162> a=(1-3*(2^-53))
a =  1.000000000000000
/tmp:163> a-.9
ans =  0.0999999999999996
/tmp:164> a-.99
ans =  0.00999999999999968


Now that is a bug in the second line due to incorrect rounding, or not?

Michael Leitner <mleitner>
Fri 16 Feb 2018 06:21:30 AM UTC, comment #2: 

BTW, I see


>> fixed_point_format (true)
>> format long
>> pi
ans =  3.14159265358979


Also, fixed_point_format is enabled by --traditional.  That seems good enough for me.


John W. Eaton <jwe>
Group administrator
Fri 16 Feb 2018 06:17:52 AM UTC, comment #1: 

I remember some discussion or bug report about this, but I don't remember the details.

Is the difference important?

I believe Matlab also scales the output (what you get with "fixed_point_format (true)" in Octave.  Do we want that by default as well?


John W. Eaton <jwe>
Group administrator
Fri 16 Feb 2018 01:05:16 AM UTC, original submission:  

I don't know if we have debated this and decide to be different from Matlab, or if Octave just became different.  According to Matlab documentation, the long format displays 15 digits after the decimal point.

Matlab


format long
pi
3.141592653589793


Octave


octave:1> format long
octave:2> pi
ans =  3.14159265358979



Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mleitner (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-23 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code