display of scalar numeric values onscreen

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

display of scalar numeric values onscreen

Rik-4
All,

I'm collecting opinions about the display of scalar values in Octave.  For
some values, the display is "x = XXXXX".  But for others, including the
default format, there is a variable number of spaces between the '='
character and the start of the number.  Sample session below

octave:12> format
octave:13> x = pi
x =  3.1416
octave:14> x = 2
x =  2
octave:15> x = 0
x = 0
octave:16> x = NaN
x =  NaN
octave:17> format long
octave:18> x = pi
x =  3.141592653589793
octave:19> format long e
octave:20> x = pi
x =    3.141592653589793e+00
octave:21> format long g
octave:22> x = pi
x =     3.141592653589793
octave:23> format rat
octave:24> x = pi
x = 355/113

Since there are separate function in pr-output.cc for scalar versus matrix
formats, we have complete control over this.  My thought is that leading
spaces don't make sense and should be trimmed to just one space after the
'=' character.  But, if an extra space is desirable to make the number
stand out from the "x =" portion then that would also be fine.  In any
case, I think we should standardize on a value rather than having it vary
confusingly.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: display of scalar numeric values onscreen

Michael Godfrey
Rik,

I vote for just one space as you recommend.

On 9/20/19 9:52 PM, Rik wrote:
My thought is that leading
spaces don't make sense and should be trimmed to just one space after the
'=' character. 

Reply | Threaded
Open this post in threaded view
|

Re: display of scalar numeric values onscreen

Olaf Till-2
On Fri, Sep 20, 2019 at 11:26:15PM +0100, Michael D Godfrey wrote:
> Rik,
>
> I vote for just one space as you recommend.
>
> On 9/20/19 9:52 PM, Rik wrote:
> > My thought is that leading
> > spaces don't make sense and should be trimmed to just one space after the
> > '=' character.
>

The extra space seems to be that of a potential 'minus' sign:

octave:1> 1
ans =  1
octave:2> -1
ans = -1
octave:3> disp (1)
 1
octave:4> disp (-1)
-1

I don't know if that is intentional. But I'd rather leave it so, so
that a number and its negative are printed aligned.

'0' makes an exception, though:

octave:5> 0
ans = 0
octave:6> -0
ans = -0

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: display of scalar numeric values onscreen

Michael Godfrey


On 9/21/19 1:54 PM, Olaf Till wrote:
> The extra space seems to be that of a potential 'minus' sign:
Hmmm. This has a point. But, the "extra" space for positive 0 seems odd,
too.

I will go with whatever Rik decides.

Reply | Threaded
Open this post in threaded view
|

Re: display of scalar numeric values onscreen

Rik-4
In reply to this post by Olaf Till-2
On 09/21/2019 05:54 AM, Olaf Till wrote:

> On Fri, Sep 20, 2019 at 11:26:15PM +0100, Michael D Godfrey wrote:
>> Rik,
>>
>> I vote for just one space as you recommend.
>>
>> On 9/20/19 9:52 PM, Rik wrote:
>>> My thought is that leading
>>> spaces don't make sense and should be trimmed to just one space after the
>>> '=' character.
> The extra space seems to be that of a potential 'minus' sign:
>
> octave:1> 1
> ans =  1
> octave:2> -1
> ans = -1
> octave:3> disp (1)
>  1
> octave:4> disp (-1)
> -1
>
> I don't know if that is intentional. But I'd rather leave it so, so
> that a number and its negative are printed aligned.
The only format I'm thinking of modifying is for scalars where there is no
other number to line up against.  The format for arrays is chosen in a
separate routine and there it is important to reserve space and line up
numbers.  For example,

format
x = [-1;1]
x =

  -1
   1

In the scalar case, the extra space seems a little strange.  It's true that
variables would still line up across octave prompts as you showed above,
but this is for the narrow case where the variable name has exactly the
same length.  In general, if programmers are using meaningful variable
names, this won't happen except by chance.  As an example, none of the
scalar variables line up in this polar-to-cartesian conversion.

octave:31> rho = 1
rho =  1
octave:32> theta = -30
theta = -30
octave:33> x = rho * cosd (theta)
x =  0.86603
 
--Rik


signature.asc (201 bytes) Download Attachment