While looking at some problems with printing 64-bit integer values with

printf, I found that Matlab's printf function silently switches from

integer formats like '%d' or '%u' to '%e' when values are not integers

or when they exceed the maximum value possible for a 64-bit integer

type. Matlab also seems to be ignoring size specifications for integer

formats, so although formats like '%hd' (short int) are accepted, there

seems to be no change in output compared to just using '%d'. And '%d'

always handles up to 64-bit integers without needing 'l' or 'll'.

I checked in the following change on the default branch:

http://hg.savannah.gnu.org/hgweb/octave/rev/491b0adfec95Now you can expect behavior like the following, which appears to be

compatible with Matlab:

sprintf('%d',intmin('int32')) %% ans = -2147483648

sprintf('%d',intmax('int32')) %% ans = 2147483647

sprintf('%d',intmin('int64')) %% ans = -9223372036854775808

sprintf('%d',intmax('int64')) %% ans = 9223372036854775807

sprintf('%d',intmin('uint32')) %% ans = 0

sprintf('%d',intmax('uint32')) %% ans = 4294967295

sprintf('%d',intmin('uint64')) %% ans = 0

sprintf('%d',intmax('uint64')) %% ans = 1.84467e+19

sprintf('%d',realmin('single')) %% ans = 1.17549e-38

sprintf('%d',realmax('single')) %% ans = 3.40282e+38

sprintf('%d',realmin('double')) %% ans = 2.22507e-308

sprintf('%d',realmax('double')) %% ans = 1.79769e+308

There is still one difference: Matlab switches to '%e' and Octave is

currently switching to '%g'. Should we follow Matlab exactly here? I

generally prefer '%g' over '%e' because it seems easier to me to read

numbers without unnecessary e+04 style exponents appended.

This change caused a few new test failures in cases where '%d' was

previously assumed to always produce an integer result. I fixed one

problem in the datestr function by rounding the printf argument that was

used with a '%d' format. I could use some help fixing the stemleaf

function since I'm not sure what the intent is there.

jwe