Re: printf integer format compatibility

[Michael D. Godfrey]

On 04/17/2014 01:24 AM, John W. Eaton wrote:
> On 04/16/2014 07:00 PM, Michael D. Godfrey wrote:
>
> > I suspect that there will be some other places where this change in the
> > behavior
> > of %d will reveal problems.
>
> Yes, I'm sure it will.  I added the following text to the NEWS file:
>
>    ** Integer formats used in the printf family of functions now work for
>       64-bit integers and are more compatible with Matlab when printing
>       non-integer values.  Now instead of truncating, Octave will switch
>       the effective format to '%g' in the following circumstances:
>
>         * the value of an integer type (int8, uint32, etc.) value exceeds
>           the maximum for the format specifier.  For '%d', the limit is
>           intmax ('int64') and for '%u' it is intmax ('uint64').
>
>         * round(x) != x or the value is outside the range allowed by the
>           integer format specifier.
>
>       There is still one difference:  Matlab switches to '%e' and Octave
>       is currently switching to '%g'.
>
> What do people think about using '%g' instead of '%e' as Matlab does?
> Should we just go ahead and use '%e'?
>
> jwe
John,

The changeset attached to bug #42132 corrects the problem in stemleaf.m.

I will think a bit about the %g vs. %e question...

Michael