-
Notifications
You must be signed in to change notification settings - Fork 54
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
Inconsistent coordinate override in arithmetic expressions #257
Comments
very good that you look into this @apfelix, there is some inconsistency indeed. However, I would not fully have the same expectation on the operations.
what do you think? |
I though a little about this, and I think your expectation does make sense. However, I'm curious on what should happen if the multiplication does involve two variables. Currently
But then how would you achieve
? If the multiplication of linopy objects should also ignore alignment, my suggestion for a consistent set of alignment rules would be the following (not sure how hard it would be to implement this):
Order of the resulting coordinates should always be defined by the first term that actually has coordinates, so numpy arrays would be ignored even if they are first. |
Interesting, let me think about it. I would like to have the API change as small as possible, as changes can lead to very much unexpected behaviour. |
Based on the discussion in #256, I started using
<variable>.loc[indices]
in arithmetic expressions and observed some inconsistencies (or I still do not understand the behaviour to 100% ^^)Following setup:
Some arithmetic expressions
level + other_time_level
works as expected, coordinates are overridden based onlevel
When using
level + alpha * other_time_level
, I would have expected to getsince I though that
alpha
would be term to define the coordinates inalpha * other_time_level
However, what I actually get is the following (coordinates of
other_time_level
are sorted according to the original time index again)Interestingly, the result changes when transforming
other_time_level
into aLinearExpression
first, i.e., calllevel + alpha * other_time_level.to_linexpr()
Finally, I tried to simply add
alpha
instead of multiplying it, i.e.,level + alpha + other_time_level
and this gives the expected result in terms of sorting the single terms into the expected rows:So my question would be: How to achieve the intended result and is all of the behaviour as it should be?
The text was updated successfully, but these errors were encountered: