bugGNU Octave - Bugs: bug #50924, Different result between range...

 
 

bug #50924: Different result between range operation and vector operation

Submitter:  None
Submitted:  Wed 03 May 2017 08:11:58 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  3 - Low Item Group:  Inaccurate Result
Status:  Confirmed Assigned to:  None
Originator Name:  Arthur HUGEAT Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 4.2.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 04 May 2017 08:39:10 AM UTC, comment #4: 

Thank you for your answers, I understand better the problem.
With range operator we sum two double variables at each step. As explained here:
https://en.wikipedia.org/wiki/Kahan_summation_algorithm
The summation between a 'little' number and 'big' number create a numerical error.
When octave create the range, the last values ('big' numbers) is add to the step ('little' number).
A possible solution is to implement the compensated summation when octave compute a range but I don't know if it's easy to do this or it's a good approach.

Arthur HUGEAT <ahugeat>
Wed 03 May 2017 03:46:19 PM UTC, comment #3: 

And a similar field for addition/subtraction?  Or possibly a stack of translate and scale factors?  Then there is also the fact that we only have real-valued double-precision ranges, not complex or float or intN ranges.  The possibilities are virtually endless  :-)

John W. Eaton <jwe>
Group administrator
Wed 03 May 2017 03:40:59 PM UTC, comment #2: 

If it didn't make the implementation too complex, it might also work to add a field to the Range class, rng_mult. This could act as a multiplication factor that is set to 1 initially, updated with operator*, and applied when accessing elements of the Range.

Mike Miller <mtmiller>
Group Member
Wed 03 May 2017 02:53:02 PM UTC, comment #1: 

The difference happens because multiplying a range object by a scalar changes the base, limit, and increment values, and then the elements (when needed) are computed using those new values.  It's as if you wrote


step:step:(n*step)


instead.  In the vector case, the values are computed by multiplying STEP by each integer in the range 1:n.

I agree that they should return the same result if possible.  OTOH, the range operator in Octave is a space optimization and the difference is less than eps.

You can completely disable Octave's special range type using


disable_range (true);


Maybe we should also have another setting that forces a range to vector conversion whenever an operation other than indexing is performed on a range object, and that operation would result in the endpoints or step no longer being integers?

John W. Eaton <jwe>
Group administrator
Wed 03 May 2017 08:11:58 AM UTC, original submission:  

When I use a range or with a vector, I haven't the same result.

n = 20480;
step = 2 * pi * 1/250e6 * 10e6;

tmp1 = step * (1:n);
tmp2 = step * [1:n];

max(abs(tmp1 - tmp2)) # Must be equal to 0


I have tested this script with octave 3.8, 4.0 and 4.2, this bug occurs but with matlab 7.11 I obtain the right result.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #40568:  go.m added by None (86B - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ahugeat (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-03 jwe Priority5 - Normal 3 - Low
        Item GroupIncorrect Result Inaccurate Result
        StatusNone Confirmed
    2017-05-03 None Attached File- Added go.m, #40568

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code