bugGNU Octave - Bugs: bug #57663, printf output doc error

 
 

bug #57663: printf output doc error

Submitter:  Francesco Potortì <pot>
Submitted:  Fri 24 Jan 2020 10:36:46 AM UTC
   
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 25 Jan 2020 09:55:33 PM UTC, comment #5: 

After reading your comments, as far as I can tell, I think that the behaviour and the docs are correct.

Sorry for wasting your time

Francesco Potortì <pot>
Sat 25 Jan 2020 07:24:17 PM UTC, comment #4: 

Can you clarify what change you consider important? Do you think it's missing something on how "precision" corresponds to the number of significant digits? The last sentence you added that starts with "In any case"?

The part that seems wrong to me is how you changed the text to say "or greater 4", the current text "or greater than or equal to the precision" is definitely correct.

Mike Miller <mtmiller>
Group Member
Sat 25 Jan 2020 07:20:11 PM UTC, comment #3: 

Yes, I get the same, and this example also looks like it matches the current documentation, right? I think your change makes the docs not agree with the current behavior.


>> printf ("%.2g ",10.^(-6:6)/3)
3.3e-07 3.3e-06 3.3e-05 0.00033 0.0033 0.033 0.33 3.3 33 3.3e+02 3.3e+03 3.3e+04 3.3e+05


In this example, the precision is 2 digits. The style of "%e" is used when the exponent is greater than or equal to 2 (e.g. "3.3e+02") or less than -4 (e.g. "3.3e-05").

Do you see how that's different from the text you proposed?

Mike Miller <mtmiller>
Group Member
Sat 25 Jan 2020 10:48:29 AM UTC, comment #2: 

This is what I get (which in my opinion is the expected behaviour:

octave> version
ans = 5.1.0

octave> printf("%.2g ",10.^(-6:6)/3)
3.3e-07 3.3e-06 3.3e-05 0.00033 0.0033 0.033 0.33 3.3 33 3.3e+02 3.3e+03 3.3e+04 3.3e+05

I find this behaviour useful and expected.

In fact, I was looking for a method to set the number of significant digits and a parameter called "precision" looks like the obvious choice.

I was surprised when I read the docs, as the behaviour I observe is the same as it is for the printf function of the C library.

According to Mathworks' docs, Matlab's printf behaves this way as well.

Francesco Potortì <pot>
Fri 24 Jan 2020 07:15:27 PM UTC, comment #1: 

The current documentation looks right to me. I think your change would make the text incorrect.

By way of example,


>> printf ("%.20g\n", 1e16)
10000000000000000
>> printf ("%.20g\n", 1e20)
1e+20


In this example, the precision is 20 digits. The style of "%e" is used when the exponent is greater than or equal to 20, otherwise the "%f" style is used.

Do you have an example that shows why you think the current doc test is in error?

Mike Miller <mtmiller>
Group Member
Fri 24 Jan 2020 10:36:46 AM UTC, original submission:  

In the Floating-Point Conversion page I read:

   The ‘%g’ and ‘%G’ conversions print the argument in the style of ‘%e’ or ‘%E’ (respectively) if the exponent would be less than -4 or greater than or equal to the precision; otherwise they use the ‘%f’ style.

The correct text should be something like:

   The ‘%g’ and ‘%G’ conversions print the argument in the style of ‘%e’ or ‘%E’ (respectively) if the exponent would be less than -4 or greater 4; otherwise they use the ‘%f’ style.  In any case the precision indicates the number of significant digits to use.

Francesco Potortì <pot>

 

(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 rik5 (Updated the item)
  • -email is unavailable- added by pot (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-28 rik5 StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2020-01-24 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code