Re: case of arguments to format function

[Rik]

On 10/10/2019 10:20 PM, address@hidden wrote:

Subject:

Re: Uppercase hex format?

From:

Andrew Janke <address@hidden>

Date:

10/10/2019 10:20 PM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<MTAwMDAzMi5ub21hZA.1570731811@quikprotect> <address@hidden> <address@hidden> <CABNpfR85XGxD=nkNRf0p2vu21tdFt_dNg653nu=address@hidden> <address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=utf-8; format=flowed

Message:

5

On 10/10/19 8:16 PM, Mike Miller wrote:

On Thu, Oct 10, 2019 at 20:01:27 -0400, Nicholas Jankowski wrote:

seems like a fairly low risk expansion of capability. Is there any case
someone can think of where this would cause a conflict of some kind?  Will
it need to extend to any other I/o or math functions?

One risk is that Matlab's format command is case insensitive. The
command "format HEX" is identical to "format hex". Some day someone may
ask for Octave's format command to accept case insensitive arguments for
compatibility.

I generally think that having different options that only differ in case
is a bad interface. A better option might be something like "format
hexupper" or "format hex upper".

Oh, yeah: I didn't notice that this was activated by a case change in the "format hex" argument.

This is exacerbated by the fact that the Matlab documentation for "format" actually lists the argument options in upper case in the first place, so "HEX" instead of "hex" is what they say to do if you want to get the normal "format hex" behavior.

Definitely "format hexupper" or "format hexu" or "format hex upper", instead of "format hex" vs "format HEX".

Cheers,
Andrew

There are lots of issues, all related to the fundamental design decision by The Mathworks to be case insensitive in the style of Windows, while Octave is UNIX-based and so respects the case of arguments.

First, there is no consistency even in documentation.  The online documentation for format (https://www.mathworks.com/help/matlab/ref/format.html) uses lower case.  Also in that vein, the code completion software built in to the IDE offers the suggestions in lower case after you type "format ".  But, Andrew is correct that executing "help format" documents the arguments in upper case.  What a mess!

By using "HEX" to indicate uppercase lettering, I was extending the interface we already have in Octave.  I presumed that this would be the least surprising way to introduce the functionality to existing programmers.  So, the first question to resolve is whether the existing case sensitive interface should be changed.  In Octave, 'format short e" prints a lower case 'e' for the exponential as in 1e3.  "format short E" prints an upper case 'E' for the exponential as in 1E3.  This also holds for "g/G".

One argument against change is that this interface has been in place for years and no one seems to have complained about it.  Although it might be correct that there is ambiguity, I'm inclined to let sleeping dogs lie.  But, if someone wants to modify this, then I think the preferred solution should be an orthogonal option so that the base interface is fully Matlab compliant.  In that case, I would argue for "format upper|lower" which would be akin to "format compact|loose" and can be specified independently of the display format.

--Rik