[Octave-bug-tracker] [bug #39832] document that "format" option can directly change "output_precision"

[Nicholas Jankowski]

Update of bug #39832 (project octave):

                  Status:               Need Info => Confirmed              
                 Summary: Describe order-dependent behaviour of "format" and
"output_precision" statements => document that "format" option can directly
change "output_precision"

    _______________________________________________________

Follow-up Comment #1:

looking at this older report and trying to understand what if any the current
documentation needs might be. there have been some changes to format in the
past decade. Currently format recognizes 3 'catogories': spacing
(compact/loose), case (upper/lower), numberdisplay (short, long, longE, +,
etc). 

 Regarding the first concern (format compact doesn't reset format, but others
do):

Octave 8.0.1

>> format default
>> pi(2,2)
ans =

   3.1416   3.1416
   3.1416   3.1416

>> format longe
>> pi(2,2)
ans =

   3.141592653589793e+00   3.141592653589793e+00
   3.141592653589793e+00   3.141592653589793e+00

>> format compact
>> pi(2,2)
ans =
   3.141592653589793e+00   3.141592653589793e+00
   3.141592653589793e+00   3.141592653589793e+00

>> format loose
>> pi(2,2)
ans =

   3.141592653589793e+00   3.141592653589793e+00
   3.141592653589793e+00   3.141592653589793e+00

>> format uppercase
>> pi(2,2)
ans =

   3.141592653589793E+00   3.141592653589793E+00
   3.141592653589793E+00   3.141592653589793E+00

>> format lowercase
>> pi(2,2)
ans =

   3.141592653589793e+00   3.141592653589793e+00
   3.141592653589793e+00   3.141592653589793e+00

>> format compact
>> pi(2,2)
ans =
   3.141592653589793e+00   3.141592653589793e+00
   3.141592653589793e+00   3.141592653589793e+00

>> format +
>> pi(2,2)
ans =
++
++

>> format loose
>> pi(2,2)
ans =

++
++

>> format uppercase
>> pi(2,2)
ans =

++
++

>>


so compact/loose doesn't impact upper/lowercase or numberdisplay., and
upper/lowercase doesn't impact compact/loose or numberdisplay.

Next:

>> format default
>> pi(2,2)
ans =

   3.1416   3.1416
   3.1416   3.1416

>> format shorte
>> pi(2,2)
ans =

   3.1416e+00   3.1416e+00
   3.1416e+00   3.1416e+00

>> format compact
>> pi(2,2)
ans =
   3.1416e+00   3.1416e+00
   3.1416e+00   3.1416e+00

>> format long
>> pi(2,2)
ans =
   3.141592653589793   3.141592653589793
   3.141592653589793   3.141592653589793

numberdisplay doesn't impact compact/loose.


last:

>> format default
>> pi(2,2)
ans =

   3.1416   3.1416
   3.1416   3.1416

>> format shorte
>> pi(2,2)
ans =

   3.1416e+00   3.1416e+00
   3.1416e+00   3.1416e+00

>> format hex
>> pi(2,2)
ans =

  400921fb54442d18  400921fb54442d18
  400921fb54442d18  400921fb54442d18

>> format shortE
>> pi(2,2)
ans =

   3.1416e+00   3.1416e+00
   3.1416e+00   3.1416e+00

>> format uppercase
>> pi(2,2)
ans =

   3.1416E+00   3.1416E+00
   3.1416E+00   3.1416E+00

>> format hex
>> pi(2,2)
ans =

  400921FB54442D18  400921FB54442D18
  400921FB54442D18  400921FB54442D18


numberdisplay doesn't seem to impact upper/lowercase.

SO, it seems to me that currently, the different format options are fairly
independent and don't 'reset' each other. 

regarding issue 2:

>> format default
>> output_precision
ans = 5
>> format long
>> output_precision
ans = 16


yes, the numberdisplay formats are  meant to directly change output_precision.
 the others though:


>> format default
>> format shorte
>> pi(2,2)
ans =

   3.1416e+00   3.1416e+00
   3.1416e+00   3.1416e+00

>> output_precision (7)
>> pi(2,2)
ans =

   3.141593e+00   3.141593e+00
   3.141593e+00   3.141593e+00

>> format uppercase
>> pi(2,2)
ans =

   3.141593E+00   3.141593E+00
   3.141593E+00   3.141593E+00

>> format compact
>> pi(2,2)
ans =
   3.141593E+00   3.141593E+00
   3.141593E+00   3.141593E+00


appropriately leave output_precision alone. 

IN SUMMARY:  it appears the 1st concern has been satisfied. will look for an
appropriate place to mention the tie between format and the output_precision
variable.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?39832>

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