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:  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

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



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

Attach Files:

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)

    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.


    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 UTC jwe Priority5 - Normal => 3 - Low
        Item GroupIncorrect Result => Inaccurate Result
        StatusNone => Confirmed
    Wed 03 May 2017 08:11:58 AM UTC None Attached File- => Added go.m, #40568

    Back to the top

    Powered by Savane 3.3