Linspace without endpoints

[antoine-levitt]

It would be very useful to have a variant of linspace that does not hit its endpoints: linspace(a,b,endpoint=false) rather than a:(b-a)/N:b-(b-a)/N and having to worry about reading it later, getting the math wrong, round-off errors maybe not giving me exactly N points, and evaluating a and b more than once. A typical use-case is representing periodic signals. Bonus points for inclusion/exclusion of left, right and both endpoints. With the new range-based linspace (#25896) the API would be a bit more awkward, but still worth it I think.

Requested for instance here https://discourse.julialang.org/t/proposal-of-numpy-like-endpoint-option-for-linspace/6916

[mbauman]

As one of the examples in that thread showed, the easier/safer workaround here is:

range(a, stop=b, length=N+2)[2:end-1]

I still think I prefer that over another keyword argument.

[favba]

Is there any performance degradation for having one more keyword? If that is not the case, I can't see what is the problem with having an extra keyword (from an users perspective). Isn't it true that we can just forget about that keyword when it is not needed?
IMHO this is worth having.

My idea is something like range(start; length, stop, step, endpoints::NTuple{2,Bool} = (true,true))

[StefanKarpinski]

All API surface costs in maintenance, documentation and complexity. This is really easy to accomplish with slicing.

[LilithHafner]

For anyone looking for this feature, range(a, stop=b, length=N+2)[2:end-1] produces a LinRange object with the same type and performance characteristics as range(a, stop=b, length=N). Slicing a LinRange produces a LinRange.