# bug #56659: Symmetry of linspace (-a, a, n)

 Submitted by: Marco Caliari Submitted on: Tue 23 Jul 2019 11:25:16 AM UTC Category: Octave Function Severity: 1 - Wish Priority: 3 - Low Item Group: Inaccurate Result Status: Fixed Assigned to: None Originator Name: Open/Closed: Closed Release: dev Operating System: Any

You are not logged in

## Discussion

Mon 23 Sep 2019 12:57:09 AM UTC, comment #8:

I changed all four RowVector.cc files in this cset (https://hg.savannah.gnu.org/hgweb/octave/rev/a8a5d2e8807f).  Octave is not exactly compatible for inputs where one or both endpoints are infinite.  This seems to me an incorrect use of linspace so I don't consider it worth fixing.  I filed a bug about it (bug #56933) just to keep track of it, but marked it "Won't Fix".

Rik <rik5>
Sat 21 Sep 2019 02:51:27 PM UTC, comment #7:

@Rik: Now the patch is fine and should be applied to all ?RowVector.cc files.

Marco Caliari <caliari>
Fri 20 Sep 2019 05:58:34 PM UTC, comment #6:

I checked using R2019b.  For the counterexample in comment #5 (a = 1.3944....), Matlab produces a symmetric vector.  Although, they get the one in comment #4 (linspace (-1.25, 0.75, 11) + 0.25) wrong which Octave would get right with my patch.

Try the next patch which passes all examples in this report.

Rik <rik5>
Fri 20 Sep 2019 06:42:49 AM UTC, comment #5:

@Rik: I was able to find this counterexample

> a = 1.3944669777885017e+01;
> x = linspace (-a,a,11);
> x == -fliplr(x)
ans =

1  1  1  1  1  0  1  1  1  1  1

that is, the middle zero is not exactly zero, which is another nice property one would like to have for symmetric linspaces.
By the way, with my matlab R2019a NONE of the examples in this bug report are symmetric. Which version did you check?

Marco Caliari <caliari>
Thu 19 Sep 2019 04:10:51 PM UTC, comment #4:

@Marco: Take a look at a different implementation which constructs all linspaces as symmetric regardless of the endpoints (Attached file linspace.dbl.diff).  I think this is preferable over having several special cases (such as x1 == -x2) because, depending on round-off error, symmettry is preserved.  See below for an Octave session with the patch applied.

octave:1> x = linspace (-1.25, +0.75, 11);
octave:2> x = x + 0.25
x =

Columns 1 through 9:

-1.00000  -0.80000  -0.60000  -0.40000  -0.20000   0.00000   0.20000   0.40000   0.60000

Columns 10 and 11:

0.80000   1.00000

octave:3> x == -fliplr (x)
ans =

1  1  1  1  1  1  1  1  1  1  1

I think some sort of change should be made.  I checked with Matlab and the linspaces they construct are symmettric for the examples given in this bug report.

Rik <rik5>
Thu 25 Jul 2019 06:20:08 PM UTC, comment #3:

After a private communication with Michael, the modification needed would be something like in the attached linspace.diff (I modified only the double version).

Marco Caliari <caliari>
Tue 23 Jul 2019 12:36:51 PM UTC, comment #2:

@Michael: I have used linspace hundreds (or thousands) of times, most of them in the symmetric case and I have never thought that the result was unsymmetric. My first example was trivial, try this one

x = linspace (-1000, 1000, 12);

I agree with you that there are several other special cases which we cannot treat. Maybe it would be enough to add an example in the documentation with a warning about the lost symmetry.

Marco Caliari <caliari>
Tue 23 Jul 2019 12:19:28 PM UTC, comment #1:

I was going to answer: because first this works only if BASE and LIMIT (in the sense of linspace's documentation) are symmetric with respect to zero, which will be fulfilled only in the minority of cases, and second because this converts a range unnecessarily to a full vector. But I have just seen that linspace does output a full vector! Is there a reason for that?

So the point is that linspace seems to construct a range by

(0:N-1)*((LIMIT-BASE)/N)+BASE

and to return the conversion of this range to a full vector. And you see, this expression is not symmetric around zero. However, it is the most accurate expression for the case where BASE==0. Of course, you could code optimized expressions for all conceivable special cases into the internal functions. But I think it is more sensible to leave that to the user: if they really feel the need to shear off the last eps/2, then they shouldn't use a general purpose function like linspace(). For your specific example, just use

x=(-5:5)/5

Michael Leitner <mleitner>
Tue 23 Jul 2019 11:25:16 AM UTC, original submission:

If you generate a vector by

x = linspace (-1, 1, 11);

you discover that it is not symmetric

> x ==-fliplr (x)
ans =

1  1  0  0  0  1  0  0  0  1  1

If you measure the difference you find

> max (abs (x + fliplr (x)))
ans =    2.2204e-16

(while it is eps/2 in matlab).
What about to correct by default the result by performing

x = (x - fliplr (x)) / 2;

at the end?

Marco Caliari <caliari>

## Attached Files

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

Attach Files:

Comment:

Attached Files
file #47554:  linspace.dbl2.diff added by rik5 (2KiB - text/x-patch)
file #47551:  linspace.dbl.diff added by rik5 (772B - text/x-patch)
file #47260:  linspace.diff added by caliari (788B - text/x-patch)

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by rik5 (Updated the item)
• -email is unavailable- added by mleitner (Posted a comment)
• -email is unavailable- added by caliari (Submitted the item)
•

Do you think this task is very important?
This task has 0 encouragements so far.

Only project members can vote.