bugGNU Octave - Bugs: bug #36278, Sprintf %d bugs

 
 

bug #36278: Sprintf %d bugs

Submitter:  None
Submitted:  Tue 24 Apr 2012 04:14:26 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  3 - Low Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  deego Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.2.4
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 03 Jan 2014 08:17:48 PM UTC, comment #7: 

I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/8c92b5e7fa4d

Given all the other things that happen before we send the value off to the C or C++ library for printing, it seems like this change will have a very small effect on performance.

John W. Eaton <jwe>
Group administrator
Thu 14 Mar 2013 05:06:08 PM UTC, comment #6: 

It would be nice if the C library behaved a bit
more reasonably:
octave:1> sprintf ('%d', 1.3e15)
ans = -701153280

could confuse people, particularly if the
results go to someplace other than the screen.

Is it hard and inefficient, to replace the
wrong answer with something like "OVFL"?
This would tend to prevent using the wrong
result as data.

Michael Godfrey <godfrey>
Group Member
Thu 14 Mar 2013 04:43:45 PM UTC, comment #5: 

From Michael's testing,


>> sprintf ('%d', 1.3e15)

ans =

1.300000e+15

>> sprintf ('%ld', 1.3e15)

ans =

1300000000000000

>> version

ans =

7.9.0.529 (R2009b)

>>


Matlab appears to be fiddling with the format conversion string when the result would overflow.  In this case, '%d' is replaced by '%e'.

Seems like there would be quite a penalty to check all numbers against the format string rather than just handing everything over to the underlying C library routine.

It is definitely a compatibility issue, but maybe we don't want to fix it.

Rik <rik5>
Group administrator
Thu 14 Mar 2013 04:03:34 PM UTC, comment #4: 

Could someone with Matlab test definitively what is done for input arguments which exceed the '%d' range?


sprintf ('%d', 1.3e15)
sprintf ('%ld', 1.3e15)


For Octave on a 64-bit architecture, the first sprintf is negative (wrong) while the second is correct.

Rik <rik5>
Group administrator
Tue 24 Apr 2012 01:10:55 PM UTC, comment #3: 

I can confirm both of these differences now, I only had 64-bit Octave available earlier.

Dave, please post replies to the bug tracker interface.

Copying Dave's followup message here, this sounds like two different bugs now.


> The other interesting thing is that the same problem does not arrive on
> 32 bits.  The 32-bit version is ok whereas the 64-bit version is not:
>
>
> on a 32-bit machine with otherwise identical setup, and with the same
> octave version.
>
> octave:1> sprintf("%d",time*1e6)
> ans = 1335271241194184
>
> This is on the 64-bit m/c:
>
> octave:1> sprintf("%d",time*1e6)
> ans = 401413026


Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2012 11:51:29 AM UTC, comment #2: 

I think this problem is a compatibility issue, so I'm reopening the report.

It looks like Matlab switches to a %e format if the value contains a fractional part or would overflow the specified integer conversion.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2012 11:23:54 AM UTC, comment #1: 

This is not a bug, your value is larger than what can be handled by the %d format specifier, regardless of 32-bit or 64-bit architecture.  Use %ld instead, that shows the same value as %.0f for me, for this example.

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2012 04:14:26 AM UTC, original submission:  

Hi All,


Bug in x64:                                                   
octave:31> (sprintf("%.0f",time*1e6))
ans = 1335236688634985
octave:32> (sprintf("%d",time*1e6))
ans = 83564835
debian stable Installed: 3.2.4-8


Anonymous

 

(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 godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-03 jwe StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-04-24 jwe Priority5 - Normal 3 - Low
        Open/ClosedClosed Open
    2012-04-24 jwe Item GroupIncorrect Result Matlab Compatibility
        StatusInvalid / Not an Octave Bug Confirmed
    2012-04-24 mtmiller StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code