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

proposal: Go 2: ability to slice in a particular dimension for multidimensional slices. #39111

Closed
JCCPort opened this issue May 16, 2020 · 10 comments
Closed

Comments

@JCCPort
Copy link

@JCCPort JCCPort commented May 16, 2020

For example, if you have the 2 dimensional slice

foo := [][]int {{1, 2, 3},
                {4, 5, 6},
                {7, 8, 9}}

you could select the second column with foo[][1] to give []int{2, 5, 8}.

@JCCPort JCCPort changed the title Ability to slice in a particular dimension for multidimensional slices. proposal: Ability to slice in a particular dimension for multidimensional slices. May 16, 2020
@gopherbot gopherbot added this to the Proposal milestone May 16, 2020
@gopherbot gopherbot added the Proposal label May 16, 2020
@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented May 16, 2020

see also #6282

this is difficult because slices represent a contiguous region of memory, to maintain that would introduce new allocations

@ianlancetaylor ianlancetaylor changed the title proposal: Ability to slice in a particular dimension for multidimensional slices. proposal: Go 2: ability to slice in a particular dimension for multidimensional slices. May 16, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 16, 2020

Thanks for the proposal. Please look through the discussion at #6282. If you have something new to suggest, by all means do so. As is I'm inclined to close this as a dup. Thanks.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 19, 2020

Slices in Go are often referred to as reference types, because if you pass a slice to a function, and the function changes an element of the slice, then the caller sees the change. Similarly, if you take a slice of a slice, and then change an element of the subslice, the change is seen in the original slice.

As far as I can see, in any straightforward implementation of your suggestion of foo[][1], that property would not hold. foo[][1] would return a new slice that does not refer to the original slice.

That seems potentially confusing.

@JCCPort
Copy link
Author

@JCCPort JCCPort commented May 19, 2020

Thanks for the response, @ianlancetaylor. From my experience in scientific computing the two main cases that have involved the feature I'm describing (in Python, numpy) would be to define a new variable that is copying the value of the multi-slice (not making a reference), or doing repeated operations to different parts of a multi-slice. I'd like to mention that this is a feature that I've used very heavily in SciComp/particle physics stuff, the implicit vectorised operations that could be done such as x = c*y[][2] where c is a constant and x is a vector allow for mathematical procedures to be chained together very succinctly.

Looking at #6282 it seems that the conversation fizzled out. Has this been discussed and dismissed somewhere else or is there still a desire for this feature from others?

@carnott-snap
Copy link

@carnott-snap carnott-snap commented May 19, 2020

Slices in Go are often referred to as reference types, because if you pass a slice to a function, and the function changes an element of the slice, then the caller sees the change. Similarly, if you take a slice of a slice, and then change an element of the subslice, the change is seen in the original slice.

If all we care about are that value changes are propagated to elements of the parent slice, that seems intuitive:

foo := [][]int {{1, 2, 3},
                {4, 5, 6},
                {7, 8, 9}}
inner := foo[][1]
inner[1] = 0
fmt.Println(foo)
// Output: [[1 2 3] [4 0 6] [7 8 9]]

But I guess that does not speak to the complexities of have a discontiguous backing array.

@seankhliao
Copy link
Contributor

@seankhliao seankhliao commented May 19, 2020

I seem to remember the scientific computing community (centered around gonum and gorgonia) wanting something similar, but the bar for language changes remains high

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 19, 2020

You may also want to look at #13253.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 19, 2020

@JCCPort I don't think I would say that the conversation in #6282 fizzled out. The language change proposal was rejected as described at #6282 (comment).

I think there is definitely room for something to be done here. However, this is a complex area. Any change to the language here has to be very clear and has to work cleanly with the rest of the language.

In particular, if this new operation is going to make a copy of the slice, then I'm pretty skeptical that it should use the same indexing syntax that slice expressions use, since that indexing syntax very explicitly does not make a copy of the slice. And if we don't use the same syntax, it's worth asking whether it could simply be a function. And whether it is possible to write that function today.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 26, 2020

Per the discussion above, we aren't going to make this change as stated. To actually make this work, we would probably need to start with a new multi-dimensional matrix type, and figure out how to slice into that.

Leaving open for four weeks for final comments.

-- for @golang/proposal-review

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 23, 2020

No further comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.