bugGNU Octave - Bugs: bug #42627, rem() treats inaccuracy...

 
 

bug #42627: rem() treats inaccuracy differently from Matlab

Submitter:  Olaf Till <i7tiol>
Submitted:  Thu 26 Jun 2014 06:21:25 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Olaf Till Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 27 Jun 2014 09:07:46 PM UTC, comment #4: 

Yeah, it seems pretty obvious now.  I added two tests and made a couple of minor edits and applied your changeset to the stable branch so this fix will be part of the 3.8.2 release:

  http://hg.savannah.gnu.org/hgweb/octave/rev/23681c9ea7ba

I think this fixes the problem, so I'm closing the report.

Thanks!

John W. Eaton <jwe>
Group administrator
Fri 27 Jun 2014 10:22:26 AM UTC, comment #3: 

See attached changeset.

We both had overlooked it --- if q=x/y is assumed to be an integer, there is no need still to do further calculations with it, but zero can be returned immediately.

I still don't understand why the case that y is an integer is dealt separately from this, but it seems to work.


(file #31627)

Olaf Till <i7tiol>
Group Member
Thu 26 Jun 2014 10:03:10 PM UTC, comment #2: 

If I remove the special treatment for numbers less than or equal to 1 in magnitude, then I still don't get exactly zero.

What change do you propose so that the result will be exactly zero in these cases?

John W. Eaton <jwe>
Group administrator
Thu 26 Jun 2014 07:05:01 PM UTC, comment #1: 

Here is the bug report that prompted that change:

  https://savannah.gnu.org/bugs/?31579

Bug #31514 that is referenced there is incorrect, it is not an Octave bug.  I think that should have referenced this report instead:

  https://savannah.gnu.org/bugs/?31512

John W. Eaton <jwe>
Group administrator
Thu 26 Jun 2014 06:21:25 PM UTC, original submission:  

As reported in this thread

http://lists.gnu.org/archive/html/help-octave/2014-06/msg00349.html


octave:1> rem(0.94,0.01)
ans =  0.0100000


while in Matlab the result is reported to be zero.

In function xrem() in liboctave/numeric/lo-mappers.h (tip of
default branch), for

xrem (x, y) and q defined as q := x / y,

there is a case distinction for abs(x) <= 1 or > 1. For abs(x) > 1, q is adjusted to an integer if its calculated deviation from an integer is less than roughly the accuracy (epsilon q) with which q is represented (by a double in this case), which seems ok. But for abs(x) <= 1, the assumed accuracy of q seems to be just epsilon, not epsilon q. A test showed me that if the case
abs(x) <= 1 were not treated special, the result would be zero (eps was 2.22044604925031e-16, abs(q-94) was greater than eps (1.42108547152020e-14, this is the special treatment of abs(x) <= 1), and abs(q-94)/94 was less than eps (1.51179305480872e-16, this is without the special treatment)).

The special treatment of abs(x) <= 1 is done the same way also for xmod.

I don't see the reason for this special treatment. It was introduced with this changeset:

changeset:   11209:94d9d412a2a0
user:        John W. Eaton <jwe@octave.org>
date:        Tue Nov 09 00:57:49 2010 -0500
summary:     improve Matlab compatibility of rem and mod

when the code was still in lo-mappers.cc, not lo-mappers.h. If Matlab compatibility was the reason, than according to the current user report the reason does not apply anymore.

Olaf Till <i7tiol>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #31627:  xmod-xrem.changeset added by i7tiol (3KiB - application/octet-stream)

 

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 i7tiol (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-06-27 jwe StatusNone Fixed
        Open/ClosedOpen Closed
    2014-06-27 i7tiol Attached File- Added xmod-xrem.changeset, #31627

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code