Mon 16 Feb 2015 09:41:10 PM UTC, comment #7:
Oh bother Matlab!
> We could have a warning about these formats when converting non-integer values. I suppose it should be disabled by the --traditional option.
If you can do that I think that is the best way to support this. It's unclear how much code relies on the current Octave implementation, but at least the warning would flush it out.
I will take a look at the 1367 instances of printf in core and fix them.
What does Matlab do with the string format specification and a double value? Does it also print out using '%g'?
|
Mon 16 Feb 2015 05:44:16 PM UTC, comment #6:
Yes, it is different.
Also, a format like '%bX' appears to say take the value, convert it to double, and print the hex representation of the bits. So that is not what you are expecting for the 15.2 value. Instead it is some 16-character hex string that represents the bytes corresponding to the double precision floating point value.
We could have a warning about these formats when converting non-integer values. I suppose it should be disabled by the --traditional option.
|
Mon 16 Feb 2015 05:27:42 PM UTC, comment #5:
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
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.
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
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?
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.
|
Sun 15 Feb 2015 11:05:01 PM UTC, comment #4:
I'm not sure that this is a bug. I think the change was made for Matlab compatibility, though it appears that Matlab uses a short e format, even for small values like 15.2. If there is a bug, I think it is not having a test for it and an explicit comment about the compatibility issue.
|
Fri 13 Feb 2015 11:18:34 PM UTC, original submission:
Real number input to sprintf, and presumably the other printf family of functions, is passing through floating point numbers without modification.
In version 3.8.2 the sample code correctly prints 'F'. This was first discovered in a gnuplot bug report and it may be causing multiple problems in the code base.
This is a blocker for the 4.0 release.
|