Re: Simultaneous "compact", "short e" and "output_precision(2)"

[Paul]

Mike Miller <mtmiller <at> ieee.org> writes:
>On Tue, Aug 20, 2013 at 16:56:46 +0000, Paul wrote: Mike Miller
><mtmiller <at> ieee.org> writes:
>>> ...the example I posted in response...does it not do what you
>>> expect?
>>
>> Yes, it does.  So my question is, how did you know to choose that
>> order?
> 
> I didn't know. I tried some combinations and that order worked.

That's the source of my concern, that we end up empirically documenting a 
collection of disparate, very specific black box behaviours of the features 
when software module behaviour is usually designed with a sensible simple 
scheme in mind.  In my past, I see such such one-offs captured in forum 
threads than the help documentation.  However....

>> What are the rules governing what settings are memorized and which
>> invocations will set/reset which settings?  To me, it doesn't seem
>> to make sense to propose documentation changes about this based on
>> a single instance what works.  It's like trying to reverse engineer
>> the design of those features and how they interact.  It makes more
>> sense to derive a description of the behaviour from the design, or
>> at least the intent as inferred from the design, and note the
>> departures from reality (which I've done with my experience).
> 
> I agree with the point you are trying to make. The reality is,
> Octave is attempting to be compatible with another software product
> whose design we do not have free access to. It may be, and often is,
> that we are not as compatible as we think and need to redefine or
> refine the current behavior. I don't know whether that is the case
> here. Do you?

OK, so that's a revelation to me.  That is, the desired behaviour isn't so 
much planned from the top down as it is tethered to Matlab.  Basically, by 
definition, the desired behaviour is what Matlab does.

That wasn't why I asked my question though.  I wasn't trying to get exact 
Matlab behaviour (though my expectations may have been shaped by past 
exposure to Matlab). I just had a need for that particular functionality in 
the situation I faced.  In fact, I'm not sure whether I can achieve it in 
Matlab.

> Here is all of the information I have on the intended behavior of
> the format function:
> 
> http://www.mathworks.com/help/matlab/ref/format.html

OK, understood.  There is no top-down planning of behaviour.  The goal is 
emulation.

> The good news is that we, including yourself, do have complete
> freedom to study the Octave source code to see how the behavior is
> currently encoded. Here is the relevant function:
> 
> 
http://hg.savannah.gnu.org/hgweb/octave/file/2946888dfa56/libinterp/corefcn/
pr-output.cc#l3595
> 
> This confirms that "compact" works the way I suspected, it is a
> boolean state that is reset by any valid format command that isn't
> "format compact".

Interesting.  I examined the code, and that fact does become clear.  But I 
would have to say that it only became clear because I knew from your 
response what to look for, and where to look.  It's been a while since I 
coded at that level.

>> If I *were* to propose a documentation change, it would simply be a
>> description of the 3 features required simultaneously, followed by
>> your coding pattern.  That seems out of place in a general help
>> document.  But that's just my opinion, though I wonder if you
>> either agree/disagree, or whether I misunderstood what you meant by
>> a documentation change proposal?
> 
> What I mean is, if you think the current text of "help format" is
> not descriptive enough with respect to your requirement, can you
> suggest text to be added that would make it clearer for you and for
> everyone?

I'll suggest how it can be augmented, based on what you described above and 
what I saw in the code.  The interaction with output_precision is there 
too, so words can be added to both "format" and "output_precision" so that 
the user knows to apply the latter after the former.

> At the very least, please submit a bug report. If you think
> something should be changed but are not sure what, the best thing
> you can do is to submit a bug report so the issue is addressed and
> not forgotten.  This discussion is public and searchable, which is
> good for others finding help, but doesn't help much with getting
> things fixed in the next version of Octave.
> 
> https://savannah.gnu.org/bugs/?func=additem&group=octave

Done.  Thanks for the pointer.