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

SetExpr/AccumBounds compute powers of the same #21407

Open
smichr opened this issue Apr 30, 2021 · 8 comments
Open

SetExpr/AccumBounds compute powers of the same #21407

smichr opened this issue Apr 30, 2021 · 8 comments
Labels

Comments

@smichr
Copy link
Member

smichr commented Apr 30, 2021

There is no handling of other being an AccumBounds so the default of (-oo,oo) is returned for

>>> AccumBounds(1,2)**AccumBounds(1,3)
AccumBounds(-oo, oo)  <-- should be (1, 8)?

When trying this with SetExpr I am not sure how to get the max or min and inf and sup don't work:

>>> SetExpr(Interval(1,2))**SetExpr(Interval(2,3))
SetExpr(ImageSet(Lambda((x, y), x**y), Interval(1, 2), Interval(2, 3)))
@jksuom
Copy link
Member

jksuom commented Apr 30, 2021

should be (1, 8)?

I think so. This case seems to be missing from AccumBounds.__pow__.

@smichr
Copy link
Member Author

smichr commented Jun 12, 2021

@jksuom , would the SetExpr be the appropriate place to allow 1**oo to be 1?

>>> from sympy.sets.setexpr import SetExpr as f
>>> f(Interval(0,1))**oo
SetExpr(Interval(0, oo))

In this context we know that no value is over 1 so can't we return SetExpr(Interval(0, 1))?

@smichr
Copy link
Member Author

smichr commented Jun 12, 2021

@oscarbenjamin , since you worked with interval that behaves the same way, is there any context in which a closed interval, [0,1], raised to an arbitrarily large number, can give [0,1] again? And how can we say "arbitrarily large" other than oo?

@jksuom
Copy link
Member

jksuom commented Jun 12, 2021

would the SetExpr be the appropriate place to allow 1**oo to be 1?

I'm not sure what SetExpr(...)**oo should represent. If it should be the union of all x**oo for all x in the SetExpr, then it looks like 1**oo should be defined as in numbers. However, if it should be considered as the limit of SetExpr(...)**n, then the result would be different. For example, [0, 1]**n would be [0. 1] for all positive integers nand so [0, 1]**oo could be [0, 1] as well. In the case of AccumBound, we definitely should consider the base as a limit.

@smichr
Copy link
Member Author

smichr commented Jun 12, 2021

In the case of AccumBound, we definitely should consider the base as a limit.

I understand why. I am just looking for someplace where the notion of 1**unlimited_positive_real == 1: either with a symbol that will behave this way or an object that will override the 1**oo behavior. Where is the branch of mathematics that can appreciate that for an expression like i/(i + 1) in nonnegative integer i can only approach 1 from the left and can never exceed 1 hence (i/(i + 1))**oo cannot exceed 1. So the response to the question ("Why is 1 raised to infinity indeterminate?") that says

when there is an expression that approaches 1 and then it is raised to the power of an expression that approaches infinity we can't determine what happens in that form. Hence, indeterminate form.

does not apply if we know that it can only approach from one side.

@smichr
Copy link
Member Author

smichr commented Jun 12, 2021

cf #14251

@jksuom
Copy link
Member

jksuom commented Jun 13, 2021

I think that #14251 could be closed. Accumulation bounds (a pair of extended reals) and sets are different kinds of objects. Instances of AccumBounds are of NumberKind. They have arithmetic methods which are different from set operations.

@jksuom
Copy link
Member

jksuom commented Jun 13, 2021

Where is the branch of mathematics that can appreciate that for an expression like i/(i + 1) in nonnegative integer i can only approach 1 from the left and can never exceed 1 hence (i/(i + 1))**oo cannot exceed 1.

It looks like that should be handled by the limits module.

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

No branches or pull requests

3 participants