Wikipedia:Reference desk/Archives/Mathematics/2016 January 17
Mathematics desk | ||
---|---|---|
< January 16 | << Dec | January | Feb >> | January 18 > |
Welcome to the Wikipedia Mathematics Reference Desk Archives |
---|
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
January 17
editWolfram Alpha- sum bug?
editI am trying to evaluate "sum of (-1)^i * cos(pi*i*k/n + pi*i) from i=0 to n-1". Wolfram Alpha tells me this sum is:
sum_(i=0)^(-1+n) (-1)^i cos((pi i k)/n+pi i) = 1/2 (sin(1/2 pi (k (1/n-2)-4 n+4))-sin((pi k)/(2 n))) sec((pi (k+n))/(2 n))
Plugging in k=40, n=5 to this sum, for example, sum of (-1)^i * cos(pi*i*40/5 + pi*i) from i=0 to 5-1 is 5. But plugging in these values to the expression for the sum you get 1/2 (sin(1/2 pi (40 (1/5-2)-4*5+4))-sin((pi 40)/(2*5))) sec((pi (40+5))/(2*5)) = approximately -8. Am I doing something stupid or does Wolfram Alpha have a bug here? And if so what is the correct expression for the sum? 24.255.17.182 (talk) 19:12, 17 January 2016 (UTC)
- It looks like Alpha is using Lagrange's trigonometric identities (or some variation) to simplify the sum. In any case, the identity only holds when the right hand side is defined, and in this case it isn't because it involves sec(45π/10). I'm not sure how you're getting the -8 value but I suspect that it the result of trying to evaluate an undefined value using finite precision arithmetic. I guess technically Alpha should be displaying something like k≠0 (mod 2n), but it's not uncommon to omit such conditions since they are taken as implicit. Try a few more "random" test values like k=7, n=41 or k=9, n=37 to avoid this issue. --RDBury (talk) 00:48, 18 January 2016 (UTC)
- Not sure if this is what we're seeing here, but it has been discovered recently that there is a bug in Mathematica (and consequently, Alpha) that causes some integrals which diverge to infinity to give a negative result instead (e.g. http://www.wolframalpha.com/input/?i=Integral+of+1%2Fy+where+x+from+0+to+1%2C+y+from+0+to+x). It might be that Alpha tried to evaluate this sum numerically using integration, and ran into this bug. -- Meni Rosenfeld (talk) 02:11, 18 January 2016 (UTC)
- Meni, that is astonishing! Is there a publicly visible bug-report, or has there been a response from Wolfram yet? Nimur (talk) 02:34, 18 January 2016 (UTC)
- ...and this only makes the software bug even more pathologically puzzling! Nimur (talk) 02:53, 18 January 2016 (UTC)
- And this shows that Alpha can't even recognize the integral representation of the natural logarithm. Egnau (talk) 16:00, 19 January 2016 (UTC)
- Well, actually that's just an instance of Alpha being "too smart for its own good". It knows that if you start running into problems. If you clarify that it is positive, it will be more cooperative: http://www.wolframalpha.com/input/?i=integral+of+1%2Fx+dx+from+1+to+t%2C+t%3E0.
- If you use Mathematica directly, it shows a bit more initiative:
- And this shows that Alpha can't even recognize the integral representation of the natural logarithm. Egnau (talk) 16:00, 19 January 2016 (UTC)
- ...and this only makes the software bug even more pathologically puzzling! Nimur (talk) 02:53, 18 January 2016 (UTC)
- Meni, that is astonishing! Is there a publicly visible bug-report, or has there been a response from Wolfram yet? Nimur (talk) 02:34, 18 January 2016 (UTC)
- Not sure if this is what we're seeing here, but it has been discovered recently that there is a bug in Mathematica (and consequently, Alpha) that causes some integrals which diverge to infinity to give a negative result instead (e.g. http://www.wolframalpha.com/input/?i=Integral+of+1%2Fy+where+x+from+0+to+1%2C+y+from+0+to+x). It might be that Alpha tried to evaluate this sum numerically using integration, and ran into this bug. -- Meni Rosenfeld (talk) 02:11, 18 January 2016 (UTC)
In[1]:= Integrate[1/x, {x, 1, t}] Out[1]:= ConditionalExpression[Log[t], Re[t] > 0 || t \[NotElement] Reals]
- I submitted a bug report back then (about 2 months ago) and the active part of the response I got was "It does appear as though integrating over the triangular region is not returning a correct result. I will spend some time seeing if this is related to a known issue, otherwise I will file an incident report with our developers regarding the issue." Haven't heard from them since, and as we can see it wasn't fixed yet. I don't know about any public bug database (though there might definitely be one).
- For context, I first heard about it in this Quora question - https://www.quora.com/Why-do-I-get-the-answer-as-infinity-but-wolfram-alphas-answer-is-1.
- And yes, the bug is weird in that it's very sensitive to how you pose the question. If you define the same triangular region in a different way, you get a correct result. If you start at a small number rather than 0, you get a correct result for some and a wrong result for some. -- Meni Rosenfeld (talk) 11:20, 18 January 2016 (UTC)
- Pretty sure, though, that has nothing to do with the issue above and Alpha is trying to use Lagrange and not numerical methods. But Alpha missed several several obvious (to humans) simplifications in the rhs and ended up obfuscating the expression instead of simplifying it.
- Specifically, on the lhs, there is the sum
- I'm guessing that Alpha didn't notice that (-1)icos(x+πi) is simply cos x and instead applied some alternating version of Lagrange stored in its database, making the simplification more difficult later on. But if you do notice that then you get, putting x=πk/n,
- by Lagrange. On the rhs you have
- or with πk/n
- Now sec(u+π/2) = 1/cos(u+π/2) = -1/sin u, so this can be written
- which matches what is given above. Note that this used the fact that n must be an integer, else the sum is undefined. So the identity is correct, though in dire need of simplification which Alpha didn't do. As a special exercise for the reader, find and fix the unbalanced parentheses I've hidden in the above expressions. --RDBury (talk) 12:40, 18 January 2016
- DoneNaraht (talk) 13:35, 18 January 2016 (UTC) (UTC)
A math professor's statement
editA bit less than a year ago, a professor said in lecture that "complex matrices are the tensor product of the space of real matrices with the complex number system". What is he referring to and how does it relate to the definition of the tensor product as stated in the article on it?--Jasper Deng (talk) 19:52, 17 January 2016 (UTC)
- Tensor product of fields, I suppose. — Preceding unsigned comment added by 88.105.40.218 (talk) 22:10, 17 January 2016 (UTC)
- What is ? (Here R is the reals (or any field) and C is the complex numbers (or any larger field).) --JBL (talk) 22:40, 17 January 2016 (UTC)
- I am not an expert, but I believe this will be the smallest field that contains and as sub-fields. Or at least a sub-field that is isomorphic to - in this case, that is the set of matrices cI where c is any complex number and I is the 2x2 identity matrix. Gandalf61 (talk) 11:37, 19 January 2016 (UTC)
- This is called the complexification of your vector space. —Kusma (t·c) 12:09, 19 January 2016 (UTC)
- Thanks. That seems to be the best answer to the question! I see that applying that operation leads to expressions of the form , so dropping the tensor product symbols and then adding the matrices component-wise gives me all the complex matrices!--Jasper Deng (talk) 20:26, 20 January 2016 (UTC)