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

You are not logged in

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

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>
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>
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>
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 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)
•

Do you think this task is very important?
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):