12-17-2014, 03:04 AM
12-17-2014, 03:20 AM
You really want to calculate Σ(sin(n)/n,n,1,1000) exactly, and then approximate? Why?
Direct in CAS: Σ(sin(n)/n,n,1,1000.) returns 1.07069 . . .
Direct in CAS: Σ(sin(n)/n,n,1,1000.) returns 1.07069 . . .
12-17-2014, 03:35 AM
with [CAS & EXACT MODE ON]
Σ(sin(n)/n,n,1,1000) =>
(1/7128865274665093053166 ...................
as it is difficult to visualize the answer, I convert to approximate
APPROX(ANS) => UNDEF
Now [CAS & EXACT MODE OFF]
Σ(sin(n)/n,n,1,1000) => 1.07069415432 ok
Σ(sin(n)/n,n,1,1000) =>
(1/7128865274665093053166 ...................
as it is difficult to visualize the answer, I convert to approximate
APPROX(ANS) => UNDEF
Now [CAS & EXACT MODE OFF]
Σ(sin(n)/n,n,1,1000) => 1.07069415432 ok
12-17-2014, 03:41 AM
Yes, I have the same settings (exact on), but I never get the answer 1/7128865.... The calc hangs. (But maybe I'm not patient enough to wait).
I see what you are saying, though . . . if you get an exact answer, you should be able to get the approximation.
I see what you are saying, though . . . if you get an exact answer, you should be able to get the approximation.
12-17-2014, 03:43 AM
(12-17-2014 03:41 AM)Helge Gabert Wrote: [ -> ]Yes, I have the same settings (exact on), but I never get the answer 1/7128865.... The calc hangs. (But maybe I'm not patient enough to wait).
I see what you are saying, though . . . if you get an exact answer, you should be able to get the approximation.
Sometimes it hangs and sometimes it doesn't. It does take a long time, but I've had it hang (to where [On][Symb] did nothing) and using the reset hole was the only way to get the calc back into working order.
12-17-2014, 08:11 AM
If you compute the sum in exact mode, the CAS does not recognize something to get a closed simple form, and the sum is rewritten with very large integers. Conversion to float requires a multi-precision floats library, that is not available on the Prime, with Xcas and MPFR inside, you get an approximation.
12-17-2014, 11:21 AM
Hello,
As was already pointed out, you should do ∑(approx(sin(n)/n,...) instead of approx(∑(sin(n)/n,...)) to avoid forcing the CAS to build really long symbolic terms.
But what makes me wonder is why the "undef" result.
For example: sum(1/k,k=1..n) returns "undef" if there aren't any assumptions made about n ("euler_gamma+Psi(n+1)" if assume(n>0)).
On the other side: sum(1/|k|,k=1..n) returns just the term I've entered (regardless of assumptions about n).
Despite both sums should return the same, I'm fine with the latter since it tells me the CAS wasn't able to find a closed form solution.
But the first result "undef" seems wrong to me (I'd expect it for such cases like 0/0 etc.) and hard to track if the sum is part of a bigger expression.
(I've set automatic simplification to "None")
As was already pointed out, you should do ∑(approx(sin(n)/n,...) instead of approx(∑(sin(n)/n,...)) to avoid forcing the CAS to build really long symbolic terms.
But what makes me wonder is why the "undef" result.
For example: sum(1/k,k=1..n) returns "undef" if there aren't any assumptions made about n ("euler_gamma+Psi(n+1)" if assume(n>0)).
On the other side: sum(1/|k|,k=1..n) returns just the term I've entered (regardless of assumptions about n).
Despite both sums should return the same, I'm fine with the latter since it tells me the CAS wasn't able to find a closed form solution.
But the first result "undef" seems wrong to me (I'd expect it for such cases like 0/0 etc.) and hard to track if the sum is part of a bigger expression.
(I've set automatic simplification to "None")