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

[Mike Miller]

On Tue, Aug 20, 2013 at 16:56:46 +0000, Paul wrote:
> Mike Miller <mtmiller <at> ieee.org> writes:
>>On Tue, Aug 20, 2013 at 15:40:11 +0000, Paul wrote:
>>> None of the 3 examples of code in my original post simultaneously
>>> activates "format compact", "format short e" and
>>> "output_precision(2)".
>>
>> Correct, but I believe the example I posted in response does,
>> though, 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.

> 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?

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

> The exact effect of the individual format statements are clear.  However,
> there is a model that the developer presumably coded to, which includes
> interaction with output_precision.  The documented behaviour should be
> derived from that, with departures in reality noted.  I've done the latter
> with the departures that I encountered.  I do not believe that it is
> appropriate to propose a documentation change about the intended behaviour
> based on the specific coding combination that got around my specific
> circumstance.  I mean, the general behaviour is driven from the top down.
> My requirement was very specific, and the fact that I didn't find anything
> about it in my web search is indicative of how specific.  It is also web
> searchable, in case anyone runs into the same need.

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".

> 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?

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

Thanks,

-- 
mike