Simple question, why? (And the answer should go to the commit message as well...)

For example, Mathematica returns Interval[{-Infinity, Infinity}] for Tan[Infinity].

As of now tan(oo) returns unevaluated object and this leads to erroneous results, like

In [5]: tan(oo)/oo
Out[5]: 0
In [4]: limit(tan(x)/x, x, oo)
Out[4]: 0

tan(x) and cot(x) also sin(x) are oscillating at infinity and Gruntz algorithm for limits evaluation doesn't handle then properly.
https://groups.google.com/forum/#!starred/sympy/h3aVz3y3n7g

I checked wolfram alpha's result before sending this pr, (I don't have access to Mathematica) and feel that returning interval(-oo, oo) for tan(oo) will help solving such limit, but for now we don't have a interval arithmetics module to handle intervals operated with expressions. I've started working to get a basic interval arithmetics module working, and will discuss it on the mailing list soon.

Maybe I should just waited till we have interval arithmetics module but returning nan for tan(oo) raises pole error for limit(tan(x)/x, x, oo) which is at least better than a wrong result.

On Thu, Dec 12, 2013 at 01:21:02AM -0800, Harsh Gupta wrote:

As of now tan(oo) returns unevaluated object and this leads to erroneous
results, like

In [5]: tan(oo)/oo
Out[5]: 0

It's a bug (in Mul.flatten), yes. But not an argument
for tan(oo)=nan (or sin(oo)=nan, as 1/(sin(oo)*oo)=0 in sympy).

Perhaps, underlying problem is x*0 == 0.

In [4]: limit(tan(x)/x, x, oo)
Out[4]: 0

I'm sure, it's just the same bug. And gruntz() returns a correct
"answer" here (it raises an exception).

Maybe I should just waited till we have interval arithmetics module but
returning nan for tan(oo) raises pole error for limit(tan(x)/x, x, oo)
which is at least better than a wrong result.

Wrong fix is better then a wrong result? I don't think so.

Hi,

• Return nan for tan and cot at infinity

Why do we want to do that? (Even in case other
functions do this under certain circumstances.)

The nan is something that originates from
floating point computations where even sqrt(-1)
gives nan according to IEEE 754.

Of course things like tan(oo) are not really
interpretable in terms of numbers. But then we
should assign either some clever symbolic
object, for example sin(oo) could give
something like Interval([-1,1]) or maybe
even better return the unevaluated symbolic
form tan(oo).

The last option follows "garbage in, garbage out".

I do not really have a strong opinion in that topic,
I just think that nan makes little sense in symbolic
computation. Therefore I'd like to see some discussion
and good arguments to use it. Maybe I'm wrong.

Perhaps, underlying problem is x*0 == 0.

We can't change this. This is core to how the flatten algorithm works. x - x becomes 0*x.

On Fri, Dec 13, 2013 at 12:19:14PM -0800, Aaron Meurer wrote:

 Perhaps, underlying problem is x*0 == 0.

We can't change this. This is core to how the flatten algorithm works. x -
x becomes 0*x.

What about slightly different defaults? For example,

1. x.is_bounded == True
   or
2. 0*x = 0, except if x.is_bounded = False.

It would need to be the default assumption.

Also, performance is a big concern here.