[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Display of strings by interpreter
From: |
Andrew Janke |
Subject: |
Re: Display of strings by interpreter |
Date: |
Wed, 23 Oct 2019 16:16:13 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 10/23/19 2:08 PM, John W. Eaton wrote:
> On 10/23/19 1:33 PM, Rik wrote:
>> On 10/23/2019 10:29 AM, John W. Eaton wrote:
>
>>> Yes, this seems like a good thing to do. Also the feature request in
>>> #56974. I would even say that we could consider displaying the type if
>>> it is double.
>>>
>>
>> Yes, it never made sense to me that Matlab would list the size and
>> type for
>> all variables except double. Be consistent, and tell the user when it
>> is a
>> double.
>>
>>> Did you want to work on either of these?
>>>
>>
>> I'll take a look at the string display issue.
>
> OK, I'll look at the data type thing.
>
> In the interest of simplicity, I think we should just make these changes
> and not make them configurable.
I agree with not making them configurable. As a maintainer, type
information is important diagnostic info. If the display were
configurable, then when you got user output in a bug report, you'd
always have to wonder "is the annotation missing because this isn't a
special type, or because the user has turned off annotations?".
I think it actually makes sense to omit the type info when the displayed
type is a double. Because doubles are the standard or default type for
numeric values in Matlab/Octave: most work is done with doubles, numeric
literals produce doubles, and using a double for pretty much anything
will probably work. (And in early Matlab versions doubles were the
_only_ numeric type.) From what I've seen, the int types are rarely used
in practice, and it's int types that cause problems because M-code does
narrowing instead of widening conversions for mixed-mode arithmetic.
(Singles narrow, too; that can cause precision issues.) So why clutter
up the command window with a "double" notation when 95% of the time
that's what it's going to be, and if doubles are the only numeric type
that doesn't have a type annotation, you can still correctly infer their
type from the absence of the annotation? (And if strings are displayed
with quotes, then you can distinguish a numeric from e.g. the string
"12.345".)
Cheers,
Andrew