[Octave-bug-tracker] [bug #44245] sprintf ("%0X", 15.2) prints floating point number 15.2 rather than 'F'

[Rik]

Follow-up Comment #5, bug #44245 (project octave):

Has Matlab really chosen to diverge from all other scripting languages?

I first tried in C to figure out what the base library call does


double x = 15.2
printf ("%0X\n", x);

When compiling:
sprintftst.c:11:3: warning: format ‘%X’ expects argument of type
‘unsigned int’, but argument 2 has type ‘double’ [-Wformat]

Run-time value
=> 3180F000


Okay, so that makes sense.  In C the format code determines how a block of
memory will be *interpreted*.

In scripting languages, however, the value is polymorphic and the format code
is a suggestion on how the output should be formatted, not what the underlying
value truly is.  If I ask for an integer display format, I expect to see
whatever underlying value there is, formatted as an integer.

I checked in Perl and Python and this is indeed what happens.


perl -e 'printf ("%0X\n", 15.2)'
F

python -c 'print "%0X" % (15.2)'
F


If Matlab is really doing this then do they also have a warning, like C, that
gets printed when you feed incorrect arguments to a format code?  That would
seem not only reasonable, but mandatory.  In effect, they are requiring a
verbose coding style where the programmer casts their inputs to the required
type ahead of printing rather than just using the programmer's intention as
specified in the printf format code.  This goes against the DRY (Don't Repeat
Yourself) principle of programming.  In the gnuplot example that uncovered
this you would have to write


sprintf ("%02X\n", uint8 (255 * color))
OR
sprintf ("%02X\n", round (255 * color))

NOT
sprintf ("%02X\n", 255 * color)


If we must follow Matlab, then we need to make the warning in the NEWS file
much more explicit and list alternatives for transitioning existing Octave
code.  We would also need to validate the Octave core code.  I just did a grep
for printf in the scripts directory and there are 1367 instances.  A lot of
these don't use integer format conversions, but we would need to check any
ones that do and figure out a workaround (probably floor() to match earlier
behavior).

Should we also be introducing the non-standard subtype fields from Matlab?


Subtype

The subtype field is a single alphabetic character that immediately precedes
the conversion character. The following nonstandard subtype specifiers are
supported for the conversion characters %o, %x, %X, and %u.

b       

The underlying C data type is a double rather than an unsigned integer. For
example, to print a double-precision value in hexadecimal, use a format like
'%bx'.

t       

The underlying C data type is a float rather than an unsigned integer.


It seems that the correct code for Matlab would then be '%bX' rather than '%X'
to get existing Octave behavior.  See
http://www.mathworks.com/help/matlab/matlab_prog/formatting-strings.html.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44245>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/