Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sub (and Add, Div, etc) not implemented for ArrayView/ViewRepr? #743

Open
jamestwebber opened this issue Oct 16, 2019 · 5 comments
Open

Comments

@jamestwebber
Copy link

jamestwebber commented Oct 16, 2019

First off, very impressed with this crate so far. I'm a long-time numpy user and I appreciate the task you took on on behalf of the Rust ecosystem.

I only recently started using Rust, so I might just be trying to do the wrong thing here, but I'm curious why an ArrayView can not be used on the LHS of a binary operation like +, -, etc. That seems like a natural use-case, since you need a read-only view of the data in the array but won't be modifying it.

In my case I'd like to compare an array of values to a particular query by broadcasting and then operate on the matching rows later–this means I can't consume the array in this operation*.

Is the appropriate thing to Zip over the rows and compare them that way? I can see how to do that but it seemed verbose, so I thought I'd check. And if this is an oversight I can try to help implement a PR.

* a broadcasting comparison operator would be even better for this but the existence of #35 suggests that might be difficult.

@jturner314
Copy link
Member

jturner314 commented Oct 16, 2019

For arithmetic operations, adding & in front of the view should work. See #237 and the docs for arithmetic operations. I've created #744 to implement arithmetic operations on ArrayView directly (so the & wouldn't be required); I'll be interested to get feedback on this idea.

For elementwise comparison of values, we can't provide direct support for the normal comparison operators (<, >=, etc.) since those operators require the result to be a bool (instead of e.g. an array of bools). For the time being, the best way to do something like this is to use Zip or azip.

I wouldn't mind adding elementwise comparison support (using methods, since we can't do it using the normal operators) so that Zip/azip wouldn't be necessary for elementwise comparison, although I'm not sure what others think about this.

@jamestwebber
Copy link
Author

Oh, right you are! I read that section multiple times and I thought I had tried that before making an issue, but I guess I was wrong. Thanks for the tip!

I think element-wise comparisons would be pretty handy as convenience functions. Or if that's deemed unnecessary it would be a worthy addition to the "ndarray_for_numpy_users" doc.

@xldenis
Copy link

xldenis commented Feb 20, 2020

Hi! I wanted to report that I find this to be a barrier to using this library in practice. I read the docs and knew it was only implemented for certain combinations of references, views, etc... but it was quite hard to figure out the right pairs in practice since all the error would say is that trait bounds weren't satisfied.

Additionally, I ended up with a very unsatisfactory solution to what should be a very simple, and common, operation.

Given a res: &mut ArrayViewMut and two a, b: &ArrayView.

I would like to do res += a.dot(b) which isn't allowed, it took me quite a while to realize that you had to deference res first. I ended up writing something using azip!. Eventually I realized the answer was * res += a.dot(b). I found that the docs didn't really help me here and that the examples were lacking.

@bluss
Copy link
Member

bluss commented Apr 25, 2020

@xldenis That is a good point, but I will note that the situation is the same for &mut f64 (a scalar) as it is for a &mut ArrayViewMut.

@xldenis
Copy link

xldenis commented Apr 25, 2020

Yea I think the problem is really that the error message is worse in the case of ArrayViewMut but I forgot what exactly the error message is and how they're different.

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

No branches or pull requests

4 participants