Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: MaskedArray _optinfo dictionary is not updated when calling __eq__/__ne__ #9279

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

Closed
wants to merge 1 commit into from

Conversation

schaefed
Copy link
Contributor

The _optinfo dictionary is not updated when calling eq/ne

@seberg
Copy link
Member

seberg commented Jun 21, 2017

While probably right (don't know this stuff well enough to say right away). This requires a test to be merged (the tests are usually in the same folder where the code is in the "tests" subfolder.

Also, please try to format your git commit according to our guidelines, such as BUG: .... Writing the text also in the git commit itself may be nice too, since it will ease understanding if anyone has to look at it again.

@seberg
Copy link
Member

seberg commented Jun 21, 2017

Otherwise, thanks for creating a PR :)

@eric-wieser
Copy link
Member

Why does MaskedArray._optinfo even exist? Is it documented? Can we deprecate it?

@schaefed schaefed changed the title MaskedArray: _optinfo update in _comparison BUG: MaskedArray _optinfo dictionary is not updated when calling eq/ne Jun 21, 2017
@schaefed
Copy link
Contributor Author

@seberg: I added a simple test and sorry for ignoring your commit message format.
@eric-wieser: I have of course no idea why _optinfo was introduced, but it is a convient way to add attributes to a MaskedArray subclass, I would miss it! I once read about it here.

@schaefed
Copy link
Contributor Author

schaefed commented Aug 6, 2017

...allright, I try to bring this issue back to the agenda by providing more details (maybe I should have done this earlier). At the moment I can add items to the _optdict attribute and the dictionary's content is usually propagated to masked arrays created during operations on the original one:

x = np.ma.ones(10)
x._optinfo['test'] = True
(x > 4)._optinfo  # {'test': True}
(x * 4)._optinfo  # {'test': True}

Only the __eq__/__ne__ methods behave differently:

(x != 4)._optinfo  # {}
(x == 4)._optinfo  # {}

I understand, that this is not a big issue for you, in the end it only affects a hardly documented feature. But it is still an inconsistency with a rather simple fix, that bit me, so I would be happy if this could be merged!
Anyhow, if you do not think that is worth it, I simply close the PR.
Cheers!

@eric-wieser
Copy link
Member

Ok, if comparison preserves it, then I think I can accept that as an argument to make equality tests do so too

def test_eq_optinfo(self):
a = array([1,2,2,4])
a._optinfo["key"] = "value"
assert_equal(a._optinfo["key"], (a == 2)._optinfo["key"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you extend this test to a bunch more operations? Arithmetic and comparison would be good.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or does a test exist for this elsewhere?)

@schaefed
Copy link
Contributor Author

schaefed commented Aug 7, 2017

Done...

@schaefed schaefed changed the title BUG: MaskedArray _optinfo dictionary is not updated when calling eq/ne BUG: MaskedArray _optinfo dictionary is not updated when calling __eq__/__ne__ Aug 11, 2017
@schaefed
Copy link
Contributor Author

Closing in favor of #9540

@schaefed schaefed closed this Aug 11, 2017
@eric-wieser
Copy link
Member

Why did you close this?

@seberg
Copy link
Member

seberg commented Aug 11, 2017

He had created it against his own master, which is tricky stuff. Possibly you can change the backing branch nowadays, not sure.

@schaefed
Copy link
Contributor Author

@seberg I haven't found a solution to do so...
@eric-wieser ...that's why I opened #9540.

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

Successfully merging this pull request may close these issues.

4 participants