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

10248: watch for non-FiniteSets when iterating an intersection #10249

Merged
merged 3 commits into from
Dec 14, 2015

Conversation

smichr
Copy link
Member

@smichr smichr commented Dec 12, 2015

fixes #10248

return (x for x in s if x in other)
for x in s:
c = other.contains(x)
if c == True:
Copy link
Contributor

Choose a reason for hiding this comment

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

c is True and c is False are much faster. if bool(c): or if bool(c) is True are probably better if you want to test equivalence.

Copy link
Member Author

Choose a reason for hiding this comment

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

bool will convert unevaluate contains results to True; fuzzy_bool can be used but then we are using a function call to convert c to True so we can use is to test it. My hunch is that this will be slower than just using the equality check.

My timeit runs show that for t = S.true, fuzzy_bool(t) == True and fuzzy_bool(t) is True essentially take the same time.

So until we do an audit and make sure that all contains routines return S.true, S.false, or an expression, it will be safer to use == True to test for S.true or True.

Copy link
Member Author

Choose a reason for hiding this comment

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

we do an audit

I did a grep for places where contains is followed by an == and changed those. I found a few others by looking for where = is followed by contains to see if a variable was used to store the result and then checked to see how it was used. I included timing info in the commit message.

If there are no objections and tests pass I will commit in about 24 h.

Although it involves a function call, sympifying a True value
and comparing like `is S.true` is significantly faster than
comparing with `==`.

>>> timeit('S.true == True',...)
12.895716891578054
>>> timeit('S.true == sympify(True)',...)
 5.6353503070422306
>>> timeit('S.true is sympify(True)',...)
 2.1583746294627275
smichr added a commit that referenced this pull request Dec 14, 2015
10248: watch for non-FiniteSets when iterating an intersection
@smichr smichr merged commit 11d6f20 into sympy:master Dec 14, 2015
@smichr smichr deleted the 10248 branch December 14, 2015 16:19

def test_issue_10248():
assert list(Intersection(S.Reals, FiniteSet(x))) == [
And(x < oo, x > -oo)]
Copy link
Member

Choose a reason for hiding this comment

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

Why does this produce a Boolean? The elements of Intersection(S.Reals, FiniteSet(x)) are numbers, not booleans.

elif c is S.false:
pass
else:
yield c
Copy link
Member

Choose a reason for hiding this comment

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

I think it would be better if it raised ValueError: Cannot determine if x is contained in the set during iteration here.

asmeurer added a commit to asmeurer/sympy that referenced this pull request Mar 20, 2019
…when iterating an intersection

This is similar to calling bool() on an undetermined relational (although in
that case we get TypeError instead of ValueError, I'm not sure which is better
here).

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

Successfully merging this pull request may close these issues.

problems converting an intersection to a list
3 participants