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

 
 

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

Submitted by:  None
Submitted on:  Wed 03 May 2017 08:11:58 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 3 - LowItem Group: Inaccurate Result
Status: ConfirmedAssigned to: None
Originator Name: Arthur HUGEATOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.2.1
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.

 

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>
Project 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>
Project Administrator
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

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

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>
Project 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.

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 File(s):
   
   
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
  • -unavailable- added by ahugeat (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 03 May 2017 02:53:02 PM UTCjwePriority5 - Normal=>3 - Low
      Item GroupIncorrect Result=>Inaccurate Result
      StatusNone=>Confirmed
    Wed 03 May 2017 08:11:58 AM UTCNoneAttached File-=>Added go.m, #40568

    Back to the top


    Powered by Savane 3.1-cleanup1