More format() changes

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

More format() changes

Rik-4
All,

Per suggestions, I changed the behavior of format when called with no
arguments to also include setting the uppercase_format variable to the
default (https://hg.savannah.gnu.org/hgweb/octave/rev/2545345f8bd9). 
Subsequently, I changed format to accept multiple arguments
(https://hg.savannah.gnu.org/hgweb/octave/rev/1ef42010c53b).  It is now
possible to set everything in one line.  For example, "format long e
compact uppercase".

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: More format() changes

siko1056
On 10/16/19 1:39 PM, Rik wrote:

> All,
>
> Per suggestions, I changed the behavior of format when called with no
> arguments to also include setting the uppercase_format variable to the
> default (https://hg.savannah.gnu.org/hgweb/octave/rev/2545345f8bd9). 
> Subsequently, I changed format to accept multiple arguments
> (https://hg.savannah.gnu.org/hgweb/octave/rev/1ef42010c53b).  It is now
> possible to set everything in one line.  For example, "format long e
> compact uppercase".
>
> --Rik
>

Thank you again Rik.  The resetting to default is now pretty
understandable.  No objections.  On the other hand, setting many options
may require much more error validation as the following scenario shows:

## Initial state
>> [a, b, c] = format
a = short
b = loose
c = lowercase

## Works, this is actually pretty nice compared to Matlab!
>> format long e uppercase compact
>> [a, b, c] = format
a = longe
b = compact
c = uppercase

## My stupid input #1
>> format long e uppercase compact short
>> [a, b, c] = format
a = short
b = compact
c = uppercase

The most right one has "won".

## My stupid input #2
>> format long e lowercase loose shor
error: format: unrecognized format state 'shor'
>> [a, b, c] = format
a = short
b = loose
c = lowercase

Especially #2 is very surprising to me.  There was an error, but changes
happened.  This is due to the way the arguments are handled one by one...

I am afraid, that Matlab intentionally lets the users enter those format
options exclusively.  For the sake of simplicity, maybe Octave should
have this limitation, as well?  There are too many evil combinations to
consider :-/

Kai

Reply | Threaded
Open this post in threaded view
|

Re: More format() changes

Rik-4
On 10/15/2019 10:44 PM, Kai Torben Ohlhus wrote:

> On 10/16/19 1:39 PM, Rik wrote:
>> All,
>>
>> Per suggestions, I changed the behavior of format when called with no
>> arguments to also include setting the uppercase_format variable to the
>> default (https://hg.savannah.gnu.org/hgweb/octave/rev/2545345f8bd9). 
>> Subsequently, I changed format to accept multiple arguments
>> (https://hg.savannah.gnu.org/hgweb/octave/rev/1ef42010c53b).  It is now
>> possible to set everything in one line.  For example, "format long e
>> compact uppercase".
>>
>> --Rik
>>
> Thank you again Rik.  The resetting to default is now pretty
> understandable.  No objections.  On the other hand, setting many options
> may require much more error validation as the following scenario shows:
>
> ## Initial state
>>> [a, b, c] = format
> a = short
> b = loose
> c = lowercase
>
> ## Works, this is actually pretty nice compared to Matlab!
>>> format long e uppercase compact
>>> [a, b, c] = format
> a = longe
> b = compact
> c = uppercase
>
> ## My stupid input #1
>>> format long e uppercase compact short
>>> [a, b, c] = format
> a = short
> b = compact
> c = uppercase
>
> The most right one has "won".

I'm okay with this behavior.  As with a light switch, you can turn it on,
off, on, off, on and it is always the last choice that prevails.  I also
think this is a pretty rare occurrence, and I would rather code for the 99%
path rather than the 1% path.  However, if it is really bothersome someone
could add a boolean that records when a format has been specified and raise
an error if this happens more than once.

>
> ## My stupid input #2
>>> format long e lowercase loose shor
> error: format: unrecognized format state 'shor'
>>> [a, b, c] = format
> a = short
> b = loose
> c = lowercase
>
> Especially #2 is very surprising to me.  There was an error, but changes
> happened.  This is due to the way the arguments are handled one by one...
There might be some relatively simple ways to handle this, although I need
a little guidance from jwe.  One method might be to use a C++ try/catch
around the existing code.  We would need to save and restore quite a few
variables (12).  Alternatively, we could use Octave's own unwind_protect
class and the protect_var method, but I'm not sure if that does what we
want in this instance which is to let the change happen, unless an error is
thrown, in which case the variable needs to be restored.  Last choice would
simply be to shadow the 12 file static variables with function local
copies, and then copy the local changes over only at the end of the
function if no error has resulted.  The last method involves the most code
re-writing, whereas the other two might be as simple as wrapping the
existing code unchanged within a block.

>
> I am afraid, that Matlab intentionally lets the users enter those format
> options exclusively.  For the sake of simplicity, maybe Octave should
> have this limitation, as well?  There are too many evil combinations to
> consider :-/
I understand the reasoning, but let's not be governed by what Matlab does. 
They have made poor architectural choices in the past and I don't want to
be constrained by that reality.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: More format() changes

John W. Eaton
Administrator
On 10/16/19 11:16 AM, Rik wrote:

> Alternatively, we could use Octave's own unwind_protect
> class and the protect_var method, but I'm not sure if that does what we
> want in this instance which is to let the change happen, unless an error is
> thrown, in which case the variable needs to be restored.

This approach is probably the simplest thing and most like other code in
Octave that needs to reset some internal program state on an error.  To
prevent the changes from reverting if there is no error, you can discard
the actions of an unwind_protect object.  I think the attached patch
should do it.

It would be a little easier if all format settings were stored in a
single object instead of as individual file-scope or global variables.
I'm headed in that direction anyway, as I think all this info should be
stored as part of the interpreter object instead of globally, but that's
  a project for another day.

jwe



format-state-diffs.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More format() changes

Rik-4
On 10/16/2019 09:11 AM, John W. Eaton wrote:

> On 10/16/19 11:16 AM, Rik wrote:
>
>> Alternatively, we could use Octave's own unwind_protect
>> class and the protect_var method, but I'm not sure if that does what we
>> want in this instance which is to let the change happen, unless an error is
>> thrown, in which case the variable needs to be restored.
>
> This approach is probably the simplest thing and most like other code in
> Octave that needs to reset some internal program state on an error.  To
> prevent the changes from reverting if there is no error, you can discard
> the actions of an unwind_protect object.  I think the attached patch
> should do it.
>
> It would be a little easier if all format settings were stored in a
> single object instead of as individual file-scope or global variables.
> I'm headed in that direction anyway, as I think all this info should be
> stored as part of the interpreter object instead of globally, but that's
>  a project for another day.

I completely agree about encapsulating all of these bits of information in
a single object for ease of use, and also that I don't have time for that
just now.  Let me take a look at your diffs and understand it, and then
I'll check it in.

--Rik