Skip to content

Conversation

@Kwonunn
Copy link

@Kwonunn Kwonunn commented Jan 27, 2026

Add a linspace_exclusive function which creates a Linspace iterator which is exclusive at its upper bound. This is essentially the same as linspace(endpoint=False) in numpy.

Addresses #1169

Add a `linspace_exclusive` function which creates a `Linspace` iterator which is exclusive at its upper bound. This is essentially the same as `linspace(endpoint=False)` in numpy.
@Kwonunn
Copy link
Author

Kwonunn commented Jan 27, 2026

If this is a welcome addition I'll add some tests and an equivalent for logspace.

I thought about using std::ops::Range as the argument for a new linspace function, which would allow something like:

let a = linspace(0.0..10.0, 32); // exclusive
let b = linspace(0.0..=50.0, 32); // inclusive

I think this is nicer and more idiomatic, but I don't see a good way of adding it that doesn't also break backwards compatibility.

@nilgoyette
Copy link
Collaborator

I think this is nicer and more idiomatic

Interesting. I do find it nicer, but this is only my opinion. What's cool is that the same name could be reused instead of creating new names like linspace_exclusive. I'm gonna need @akern40 opinion on this matter.

@akern40
Copy link
Collaborator

akern40 commented Jan 28, 2026

Strongly agree, I love this approach, so my question is how we can make a smooth transition (or we'll just have to make a warning somehow?)

@Kwonunn
Copy link
Author

Kwonunn commented Jan 29, 2026

Since Rust doesn't do function overloading there really are only two options:

  1. Make a new function with a name like linspace_range, put a deprecation warning on the old one and tell people to migrate over.
  2. Change the function signature of linspace, which would be a backwards-incompatible change.

I don't know how opposed you are to these kinds of API changes, I'll leave it to you to decide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants