Doit method in concrete

[Anderson Bhat]

Hello guys , I am working on couple of Pr's extending the functionality of the doit method in the concrete module , I noticed that one inconsistency leads to couple of errors . Product(1, (n, 1, oo)).doit() returns 1 and 1**oo returns NaN. Other integers work as expected . These expressions are equivalent right ??? or am I missing something !

[Oscar Benjamin]

On Sat, 6 Nov 2021 at 11:58, Anderson Bhat <anderso...@gmail.com> wrote:
>
> Hello guys , I am working on couple of Pr's extending the functionality of the doit method in the concrete module , I noticed that one inconsistency leads to couple of errors . Product(1, (n, 1, oo)).doit() returns 1 and 1**oo returns NaN. Other integers work as expected . These expressions are equivalent right ??? or am I missing something !

The expression 1**oo is indeterminate because there are different ways
that you could arrive at this form that have different limits:

In [31]: limit((1 + 1/n)**n, n, oo)
Out[31]: ℯ

In [32]: limit((1 + 1/n**2)**n, n, oo)
Out[32]: 1

In [33]: limit((1 + 1/sqrt(n))**n, n, oo)
Out[33]: ∞

The product in your case defines a particular limit so it is not indeterminate:

In [38]: Product(1, (n, 1, m)).doit()
Out[38]: 1

In [39]: limit(Product(1, (n, 1, m)).doit(), m, oo)
Out[39]: 1

--
Oscar

[Peter Stahlecker]

I am just a hobby mathematician, but it seems to me like this:

1^oo := lim(1^n) = lim(1) = 1.

The other 'limits' seem to me to be an inadmissible 'exchange' of limits:

1 != (1 + 1/n) for any finite n 

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTS%2BA32brrRS7xZ7Rr7kJ%2BLG%2BxJ6Jre1sys8_iHVzZ7tg%40mail.gmail.com.

--

Best regards,

Peter Stahlecker

[Chris Smith]

There are ways to protect the path leading to `1**oo` but the expression itself is agnostic to path. An appeal that it give 1 has been made here: https://github.com/sympy/sympy/pull/21619

/c

[Anderson Bhat]

Thanks a lot for the answers ,makes more sense to me now . Just thought of asking this because I realized that there are some use cases of the above . 

A simple one being that some expressions of the form  Product( f(x) , (x , 1 ,oo)).doit() which would eventually diverge could return oo instead of returning self like 

x = Symbol('x' ,integer =True, Positive=True)

Product( x , (x , 1 ,oo)).doit()

Product(1 +1/x**S(2/3) , (x, 1 ,oo)).doit()

As these calculations would involve 1**oo in the code workflow , returning 1 instead of nan would solve the problem as per our convenience but wasn't sure if it's correct in all Mathematical aspects !!!!!

What I personally felt or rather what I used to believe without much mathematical insight was that 

" anything tending to 1 and not exactly 1" raised to the power of " anything tending to oo (always the case as oo is not exact /defined )" should give nan and correctly represents an Indeterminant form .

Like we do in case of limits 

In [32]: limit((1 + 1/n**2)**n, n, oo)

Out[32]: 1

Here the expression  tends to 1 and is not exactly 1 . 

But .....

" exact 1 " raise to the power of "anything tending to infinity" would be 1 !!!

I will surely give more thought about this considering mathematical correctness and other aspects!

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3204172b-dd2b-4356-9bd8-d96fbfe09a5fn%40googlegroups.com.

[Oscar Benjamin]

On Sat, 6 Nov 2021 at 16:55, Peter Stahlecker
<peter.st...@gmail.com> wrote:
>
> I am just a hobby mathematician, but it seems to me like this:
>
> 1^oo := lim(1^n) = lim(1) = 1.
>
> The other 'limits' seem to me to be an inadmissible 'exchange' of limits:
> 1 != (1 + 1/n) for any finite n

When implementing the internals of a computer algebra system you have
to be careful because the "input" expressions might arrive indirectly.
You have to think: what possible previous operations could have
resulted in the situation I have now which is to evaluate 1**oo? There
are many possible answers to that and they correspond to different
final answers. In general using oo in expressions is not well defined
if we don't specify how the limit should be taken but in certain cases
the result is the same in any case. Otherwise as the zen of Python
says:
"""
In the face of ambiguity, refuse the temptation to guess.
"""

--
Oscar

[Peter Stahlecker]

Your explanation makes eminent sense!

I did not think of this at all: surely a term 1^oo does not drop out of the sky, it has a ‚history‘.

Thanks!

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTWVCrdQvHzpPuUh7Uz1JiP6j2HC%2BNsSpSm5YiY3jtK%2BA%40mail.gmail.com.