-
Notifications
You must be signed in to change notification settings - Fork 41
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
General subscripting #3395
General subscripting #3395
Conversation
Thanks @HansOlsson for your proposal to resolve this issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is the characterization of how a matrix-valued expression should be indexed.
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Phone meeting: Shouldn't close before we have new issue for type of array expressions, but it can be closed later. |
Added #3410 - note that it is even more restrictive than I thought. |
Looking more closely at the text I see that we already have very drastic restrictions on non-Integer subscripts. So, the text that looks like a new restriction here was in fact implicitly present (if the operations generated anything else it could barely be used) - I still think it good to have as a normative text, instead of changing it to non-normative. The new issue is also opened. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting that we avoid making statements that are dependent on the resolution of #3410.
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Should be resolved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Assuming that the example listing has been verified to fit the page width.
Add general subscripting also to Modelica.
Closes #2659
As noted in that ticket the previously discussed blocking cases are basically irrelevant.
An alternative to stating that all operations generate arrays indexed by 1...n is to state that general subscripting transforms the arrays to such a form - the downside is that
(a)[1]
isn't the same asa[1]
- the upside is that(a)[1]
is valid regardless of how the array is subscripted.The end effect should be similar.