-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: Multi-dimensional slices #41129
Comments
Unless the concerns in #6282 are addressed, the mere passage of time should not change the decision that was made before |
#6282 is a long discussion so it deserves a recap. There are no critical standing concerns to be addressed, the go team acknowledged that this is a valid point and though the proposal is not 100% perfect, it is justified and should be brought up to more mature discussion when people will start discussing go2 more seriously. Here is the original decision, to quote @griesemer :
This issue fell between the cracks and was frozen due to age. It should be revived. |
But someone still needs to come up with a new and improved design. Opening this issue doesn't help without that. |
This is a difficult feature. Somewhat analogous to generics, a good design is not something that appeared over night. It required significant engineering efforts, including involvement also from the core go dev team. And a since a good design is going to require a community effort, this will not be solved unless a problem is categorized, discussed and tracked, which it was not. I am arguing that this is a valid problem that was put aside because it was a tough problem that came in a time where the go language was not open to changes. Though I have the capability to present a design, I think this would be presumptuous and I believe that bringing everyone to discuss this is the important first step. It is true that I should involve the gonum team in this. I am hopeful. |
I agree with what you say. My point is a different one. This isn't how we use the issue tracker, and, in general, this kind of discussion does not work on the issue tracker. The problem is that the issue tracker is not threaded, and the GitHub interface starts hiding comments when there are too many of them. A better place for this kind of discussion is a mailing list. So by all means have the discussion. Just don't do it here. Thanks. |
@ianlancetaylor I completely agree with you on this one. I think the original issue staled because it was too big of a discussion. My plan for now is to make an Experience Report which was not submitted for the original issue, because experience reports did not exist at the time of original proposal. And move with the community to a refined proposal. EDIT: having gone more deeper into all of the prior proposals, I just noticed now that @ianlancetaylor was behind #13253, I apologize for not noticing that and crediting your work in the original post. I was not fully aware of the alternative proposal at the time. |
For the sake of discussion, let's assume Go had support for multi-dimensional slices. Such slices would need to support a certain set of operations, such as creation/allocation of those slides, the ability to index elements, possibly iteration over the elements, maybe element-wise operations (adding two matrices), etc. Also for the sake of discussion, I am going to make a few claims:
In summary, what we need is full programability of (memory) layout. And with programmability of layout we also need programmability of operations, as they depend on the layout.
So if anything is missing it's perhaps convenience of notation, i.e., syntax.
To make progress here we need to have strong arguments as to why these claims are wrong. There's one thing we could do on the syntax side: we could perhaps support indexing methods. If we declare methods such as type Matrix[T Numeric] struct ...
func (m *Matrix[T]) [] (i, j int) T ... // getter: x = m[i, j] translates to x = m.[](i, j)
func (m *Matrix[T]) []= (i, j int, x T) ... // setter: m[i, j] = x translates to m.[]=(i, j, x) we could implement multi-dimensional data structures in libraries yet provide notationally convenient access to the elements. Such methods would only accept a prescribed signature (n integer arguments and a result or argument of a given element type). (See also https://www.dotconferences.com/2016/10/robert-griesemer-prototype-your-design.) |
Based on the discussion above, this proposal is a likely decline. Discussing the topic is fine but there is no detailed proposal here. Leaving open for four weeks for final comments. |
Thank you for giving me the time to do the required homework on this. The post by @griesemer and your past works gave me extremely valuable food for thought. I have written and published an experience report on this issue and linked it to the official experience reports page. I could not have done this work without all the collective past contributions of the Go community and the core Go dev team. I became convinced, only after the completing it, that the solution proposed by @griesemer:
I am proposing that you consider index operator methods as proposed by @griesemer as the right solution to this problem and I do hope that you reach the same conclusion after you read my experience report. Thanks again for this opportunity. |
A 15 Years of array programming experience report (and what makes python success today): Harris, C.R., Millman, K.J., van der Walt, S.J. et al. Array programming with NumPy. Nature 585, 357–362 (2020). https://doi.org/10.1038/s41586-020-2649-2 |
Hello, author of gorgonia.org/tensor here. Hope you don't mind me chiming in. The I think @griesemer merely scratches the surface of the issues with making multidimensional slices. I also think there may be some benefits to additional accessor syntax. Just not in the way most would imagine it. Here's an example: Assume
In Python/Numpy, it'd look like this:
The latter is very much cleaner than the former. Ideally with the Just having it as a plain accessor (as suggested) isn't going to do much though. You could currently do something like this:
Going from that to this:
brings little utility. When programming with arrays, you seldom set values like this. Instead you typically set values in batches. So, using the same
This is doable with some slight modification to the extension that @griesemer proposed, e.g.
where U is defined
Numpy's killer feature is the ability to slice with syntax and I think Go should have them too. Of course, the problem is if you allow this, then abuses of syntax extensions will be abound. So we gotta balance that as well. |
Thanks @chewxy. I completely agree with you. I apologize for not being clear on this. Whether this is:
or
Doesn't change much on my part. As long as we are adding As for syntax abuse, you can abuse interface{} with function calls today. I think Go programmers have learned not to abuse it and I don't think its any different. |
You can find a proposal which is based on the proposal template here. Thanks again for your time. |
There was further discussion, but no change in consensus on this particular proposal. |
This proposal was originally denied back in 2014, not because it was unjustified, but because the go team said that go1 was, justifiably, stable, with the argument that consideration of this should be deferred to go2.
Its 2020 and data science, machine learning and AI are more important today than ever.
There are some really compelling arguments for why go can be the next disruptive language for data science.
I would like to thank @btracey and the gonum team for their originally written proposal.
Please do reconsider.
The text was updated successfully, but these errors were encountered: