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

[Paul]

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

>   format % reset all formatting to defaults
>   format short e % precision is now 5, compact appears to be off
>   format compact
>   output_precision (2)
>   x = rand (5)
>
>   x =
>    5.2e-01   4.4e-01   8.0e-02   2.2e-01   8.5e-01
>    7.2e-01   9.1e-01   2.8e-01   8.7e-01   6.2e-01
>    5.0e-01   9.9e-01   8.4e-01   9.5e-01   5.2e-01
>    9.5e-01   3.2e-01   8.1e-02   2.5e-02   8.7e-01
>    4.8e-01   1.9e-01   9.4e-01   2.3e-01   8.3e-01
> 
>> The exact circumstances and statement ordering giving rise to which
>> combination of effects is a black box from my point of view.
> 
> I think the ordering and effects between "format short", "format
> long", and "output_precision" are fairly clear in the documentation.
> The one that I agree may be a bit unclear is attempting to combine
> those with "format compact" as above.

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.

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?