bugGNU Octave - Bugs: bug #44245, need configurable warning when...

 
 

bug #44245: need configurable warning when sprintf format contains integer code, but value is real number

Submitted by:  Rik <rik5>
Submitted on:  Fri 13 Feb 2015 11:18:34 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  John W. Eaton <jwe>
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 02 Mar 2015 08:36:29 PM UTC, comment #10:

Re-titling for the remaining issue. Dropping severity to normal since this will no longer gate the 4.0 release.

Rik <rik5>
Project Administrator
Tue 17 Feb 2015 12:54:34 AM UTC, comment #9:

I checked in a cset where I attempted to find all uses of printf with integer format codes and ensure that the inputs were, in fact, integers (http://hg.savannah.gnu.org/hgweb/octave/rev/5f2c0ca0ef51).

Rik <rik5>
Project Administrator
Mon 16 Feb 2015 10:57:01 PM UTC, comment #8:

I think Matlab uses '%e' instead of '%g'. Maybe we should just do that too.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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'?

Rik <rik5>
Project Administrator
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.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
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.

Rik <rik5>
Project Administrator
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.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Fri 13 Feb 2015 11:41:43 PM UTC, comment #3:

It wasn't quite as certain that the other bug, #42235, was as serious and therefore of Severity Blocker.

Rik <rik5>
Project Administrator
Fri 13 Feb 2015 11:26:25 PM UTC, comment #2:

Should both bugs be blockers? They are both regressions, right? Both are likely unintended consequences of changes I made, so I'll try to take a look at them. I claimed the other bug as well.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Fri 13 Feb 2015 11:20:12 PM UTC, comment #1:

See also bug #42235 which is also related to changes made to the printf family of functions and could possibly be fixed at the same time as this bug.

Rik <rik5>
Project Administrator
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.

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-02 rik5 Severity5 - Blocker => 3 - Normal
        Summarysprintf ("%0X", 15.2) prints floating point number 15.2 rather than \'F\' => need configurable warning when sprintf format contains integer code, but value is real number

    Back to the top


    Powered by Savane 3.3