bugGNU Octave - Bugs: bug #32991, format long shows more decimal...

 
 

bug #32991: format long shows more decimal digits than can possibly be accurate

Submitted by:  Pedro Quaresma <pedroquaresma>
Submitted on:  Mon 04 Apr 2011 10:23:26 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Wont FixAssigned to: None
Originator Name: Pedro QuaresmaOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 22 Jun 2013 10:40:03 AM UTC, comment #5:

The behavior of Octave is clearly documented in "help format" as

so the behavior of octave should not be considered a bug. I'm closing this report

D.

David Bateman <dbateman>
Project Member
Thu 07 Apr 2011 02:09:16 PM UTC, comment #4:

I agree with this last comment in one point, but I disagree in another point:

"Users of floating point arithmetic should know the limitations or they shouldn't be using floating point arithmetic at all"

I agree.

But I do not agree with the solution adopted by Octave. It is not a calculus bug (I see now that it is not, thank you for all the comments), but, in my opinion, it is a "display bug", Octave shouldn't display

octave:3> 322426889*404781269
ans = 130512365289142144

the format long should not display, as integers, numbers that are out of range for a correct representation, it is misleading.

Pedro Quaresma <pedroquaresma>
Thu 07 Apr 2011 11:41:04 AM UTC, comment #3:

Consider the case of "format long eng" which is even worse. In engineering format (exponent divisble by 3) we have three choices

1) Displaying exactly the right number of digits but with a ragged display of the numbers which is rather ugly
2) Possibly display too few digits, but get the alignment of the number in a matrix correct
3) Possibly display too many digits, but get the alignment of the number in the matrix correct

consider

format long eng
1000*randn(10,3)

in Octave and Matlab. Matlab made the choice 1) and in Octave I made the choice 3)..

If this bug report is considered a bug then the behavior of "format long eng" is also a bug. Frankly I consider neither this bug report nor the behavior of "format long eng" as a bug. Users of floating point arithmetic should know the limitations or they shouldn't be using floating point arithmetic at all.

D (David Bateman posted anonymously as I don't have access to my dev machine)

Anonymous
Mon 04 Apr 2011 05:15:31 PM UTC, comment #2:

And if you do need to be doing precise integer operations, you should consider the integer classes (int8, uint8, int16, ...). In particular,

You still need to consider overflow which you can do with the intmax function. For example,

Rik <rik5>
Project Administrator
Mon 04 Apr 2011 03:50:41 PM UTC, comment #1:

An IEEE 754 double has a 52-bit mantissa, so the largest integer that can be represented accurately is 2^52-1, and that's approximately 15 or 16 decimal digits. Your result is much larger than that, so it can't be represented accurately.

The bug, if it can be deemed a bug, is that format long is displaying too many decimal digits. It should never display more than 16. Since this is still visible in the dev version, I'm retitling this bug and marking it for the current dev version.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Mon 04 Apr 2011 10:23:26 AM UTC, original submission:

Given the commands

octave:2> format long
octave:3> 322426889*404781269
ans = 130512365289142144

the correct result is 130512365289142141

The result is obviously wrong 9x9=81 so the product cannot end with a 4.

And if I do

octave:4> 130512365289142141/322426889
ans = 404781269
octave:5> 130512365289142141/404781269
ans = 322426889

Is it a problem of overflow? It is strange, the two results differ by 3.

Pedro Quaresma
University of Coimbra, Portugal

Pedro Quaresma <pedroquaresma>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dbateman (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by pedroquaresma (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 22 Jun 2013 10:40:03 AM UTCdbatemanOpen/ClosedOpen=>Closed
    Sat 22 Jun 2013 10:40:02 AM UTCdbatemanStatusConfirmed=>Wont Fix
    Mon 04 Apr 2011 03:50:41 PM UTCjordighStatusNone=>Confirmed
      Release3.2.4=>dev
      SummaryIncorrect result, product of bignumbers=>format long shows more decimal digits than can possibly be accurate

    Back to the top


    Powered by Savane 3.1-cleanup1