format short output with small numbers (bug #56936)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

format short output with small numbers (bug #56936)

Rik-4
All,

What should happen when we display small numbers with "format short"
(default)?  Should we end up printing a lot of zeros?  That is what happens
now.

x = [-pi;0;pi];
x*1e-6
ans =

  -0.0000031416
              0
   0.0000031416

In earlier Octave versions we would switch over to scientific notation at a
certain point.  These are the results from version 3.4.3

octave-3.4.3:5> x*1e-3
ans =

  -0.0031416
   0.0000000
   0.0031416

octave-3.4.3:6> x*1e-4
ans =

  -3.1416e-04
   0.0000e+00
   3.1416e-04

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: format short output with small numbers (bug #56936)

John W. Eaton
Administrator
On 9/23/19 5:14 PM, Rik wrote:

> All,
>
> What should happen when we display small numbers with "format short"
> (default)?  Should we end up printing a lot of zeros?  That is what happens
> now.
>
> x = [-pi;0;pi];
> x*1e-6
> ans =
>
>    -0.0000031416
>                0
>     0.0000031416
>
> In earlier Octave versions we would switch over to scientific notation at a
> certain point.  These are the results from version 3.4.3
>
> octave-3.4.3:5> x*1e-3
> ans =
>
>    -0.0031416
>     0.0000000
>     0.0031416
>
> octave-3.4.3:6> x*1e-4
> ans =
>
>    -3.1416e-04
>     0.0000e+00
>     3.1416e-04

As I recall, Matlab uses a multiplier (Octave's fixed_point_format
setting that is enabled when using --traditional).  But that doesn't
account for the case you show above where it may show 0.00000 for small
values instead of showing any digits.  For example, something like

   fixed_point_format (true);
   pi * [1e6; 1e-6]

I chose to switch automatically to avoid confusion because people might
think that "0.00000" is exactly zero.  At that time, I don't remember
Matlab displaying "0" to mean "exactly zero" (a feature that I like,
BTW, thanks for making that change).

For those who want the display to be more like Matlab, is it sufficient
to set fixed_point_format to true?  If so, then I'm not sure that there
is anything we need to change, unless you are proposing that we enable
fixed_point_format by default.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: format short output with small numbers (bug #56936)

John W. Eaton
Administrator
On 9/24/19 1:19 PM, John W. Eaton wrote:

> On 9/23/19 5:14 PM, Rik wrote:
>> All,
>>
>> What should happen when we display small numbers with "format short"
>> (default)?  Should we end up printing a lot of zeros?  That is what
>> happens
>> now.
>>
>> x = [-pi;0;pi];
>> x*1e-6
>> ans =
>>
>>    -0.0000031416
>>                0
>>     0.0000031416
>>
>> In earlier Octave versions we would switch over to scientific notation
>> at a
>> certain point.  These are the results from version 3.4.3

I realize I may have missed the point of your question.  If the behavior
changed, then I don't know that it was intentional.  Is the situation
now that there is no point where the switch happens?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: format short output with small numbers (bug #56936)

John W. Eaton
Administrator
On 9/24/19 1:22 PM, John W. Eaton wrote:

> I realize I may have missed the point of your question.  If the behavior
> changed, then I don't know that it was intentional.  Is the situation
> now that there is no point where the switch happens?

There is definitely something strange going on.  It seems to be
dependent on whether an exact zero is present in the array:

octave:7> pi* [1e7;0;1e-7]
ans =

    31415926.53590
                 0
           0.00000

octave:8> pi* [1e7;1e-7]
ans =

    3.1416e+07
    3.1416e-07

Maybe that's due to the use of logarithms to calculate magnitude ranges?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: format short output with small numbers (bug #56936)

Rik-4
In reply to this post by John W. Eaton
On 09/24/2019 11:19 AM, John W. Eaton wrote:

> On 9/23/19 5:14 PM, Rik wrote:
>> All,
>>
>> What should happen when we display small numbers with "format short"
>> (default)?  Should we end up printing a lot of zeros?  That is what happens
>> now.
>>
>> x = [-pi;0;pi];
>> x*1e-6
>> ans =
>>
>>    -0.0000031416
>>                0
>>     0.0000031416
>>
>> In earlier Octave versions we would switch over to scientific notation at a
>> certain point.  These are the results from version 3.4.3
>>
>> octave-3.4.3:5> x*1e-3
>> ans =
>>
>>    -0.0031416
>>     0.0000000
>>     0.0031416
>>
>> octave-3.4.3:6> x*1e-4
>> ans =
>>
>>    -3.1416e-04
>>     0.0000e+00
>>     3.1416e-04
>
> As I recall, Matlab uses a multiplier (Octave's fixed_point_format
> setting that is enabled when using --traditional).  But that doesn't
> account for the case you show above where it may show 0.00000 for small
> values instead of showing any digits.  For example, something like
>
>   fixed_point_format (true);
>   pi * [1e6; 1e-6]
>
> I chose to switch automatically to avoid confusion because people might
> think that "0.00000" is exactly zero.  At that time, I don't remember
> Matlab displaying "0" to mean "exactly zero" (a feature that I like, BTW,
> thanks for making that change).
>
> For those who want the display to be more like Matlab, is it sufficient
> to set fixed_point_format to true?  If so, then I'm not sure that there
> is anything we need to change, unless you are proposing that we enable
> fixed_point_format by default.
>

Answering this and the other questions as well.

First, no, I'm not particularly interested in turning on fixed_point_format
by default.  I think it's okay, and people should have the option if they
want it, but it's not my preferred display.

Second, yes, there has been a change in the way "format short" displays
large values.  I don't think that was intentional, and probably counts as a
regression.

Third, yes, Octave never switches over to scientific notation now for
"format short" which means "pi* [1e7;0;1e-7] " will display awkwardly as

octave:1> pi* [1e7;0;1e-7]
ans =

   31415926.53590
                0
          0.00000

which simultaneously has too many digits for the first entry and too few
for the third entry (so someone might mistake it for zero).

--Rik