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

[Paul]

Jordi Gutiérrez Hermoso <jordigh <at> octave.org> writes:
>On 20 August 2013 22:54, Paul <Paul.Domaskis <at> gmail.com> wrote:
>> 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
> 
> There isn't anything black about it:
> 
>     
http://hg.savannah.gnu.org/hgweb/octave/file/8520c264619c/libinterp/corefcn/
pr-output.cc
> 
> There's no need to be guessing what "format" does. We can know. If
> the documentation and the behaviour are out of synch, they should be
> brought back into synch, but there are no secrets of operation here.

Jordi, I realize that the more organic programming approaches of today do 
not necessarily follow the practices of past decades, where you sit down 
and determine the operational behaviour requirements of the product/module 
and the interface before starting to code.  I suspect that reverse 
engineering the macroscopic behaviour from the code is normal mode of 
operation in open source.  Mike already implied that quite well in 
describing Octave's goal of reactively aligning its behaviour to Matlab.  
It doesn't seem to be as top down as I'm use to thinking of coding.  This 
ground has been well covered in the post to which you responded, and he 
provided the link to the code.  Thanks.