This is what I mean about sin(x).  This I believe is the source of the problem.  How can I get this to work because for sufficiently small x the sin(x)-->x & sin(nx)-->nx?  Actually if n is HUGE then the numerator should still be sin(nx).  So the integral will still be problematic?  This is probably analagous to the situation with the sinc function?  I will try to look up that situation.  Hopefully, I will have some luck.  In the meantime if anyone has any suggestions please respond.

Download evaluating_integral.mw

I changed the lower integral bound to a & MAPLE still will not evaluate the integral.  See below:
 

Download evaluating_integral.mw

@acer 

I don't have Maple 12 on hand right now, and so I've run this below in Maple 16.02. If your Maple 12's solve command doesn't accept the allsolutions option then try replacing instances like,

solve(..., alpha, allsolutions);

with,

_EnvAllSolutions := true:
solve(..., alpha);

You are correct I need to use _EnvAllSolutions, but it expresses the answer in an awkward manner.   Anyway the manner in which it is expressed it is not readily interpreted by the layman.  Maybe I applied the command incorrectly?

Download All_solns.mw

@acer 

By the way, I could be wrong, but if you combine and simplify before solving for alpha then can't it be shown that your last step is just trying to generate the solutions for the following?

sin(alpha) = n*sin(2*Pi*t/T)

In essence yes.  What I was doing was taking a solution to a series representing a jump discontinuity that has been published.  That solution used some mathematic gymnastics to arrive at the solution.  I was attempting to find the solution without resorting to such tactics.  Furthermore, I am attempting to extend the solution method to functions that not only have jump discontinuities, but also discontinuities that extend also to the derivatives of the function.  One particular function of interest is called a "Friedlander" waveform * & periodic modifications to it.  I ma still working on this & maybe will post more on this at a later time because I am sure I will run into technical issues with MAPLE again.

See the end result in the link below:

trig_series_solns.mw

It appears MAPLE only spits out the lowest order solution.  Is there another command that should be used for solving trig functions to indicate that solutions repeat themselves or does the user simply needs to realize that; ie- a solution @ pi/2 repeats again @ 3/2*pi?

Here is even a simpler example that test relation & is chokes on.  Do later versions of MAPLE have the same problem?
 

Download identically_equal.mw

@acer 

OK, your opinion was the 2 questions should fall under 1 thread.  How so?  One had to do with the INERT vs ACTIVE for of the sum & integration operations.  The other had to do with the ROUNDOFF error issue which you answered yourself, but I do not think it was addressed adequately.  You did show convergence for higher number of terms in the series, but I still do not see how the error was so VASTLY huge for the 1 case over the other 3.  So that question is still out there & has not been addressed by anyone else because you have already earmarked it as ANSWERED by you..

So if I have another question that can be remotely related to a previouls question you are going to delete it?  Let me ask you this, if the question is 6 months old & has already been earmarked as ANSWERED then how would someone be provoked to read over the question?  Any new twist will go UNREAD?

I find this unilateral moderator of posted questions a bit repressive.  Are you the only one responsible for this?

@acer 

I changed the argument of the trig functions from 2*pi*(k-1)*x/T to 2*pi*k*x/T & now have VERY GOOD concurrence among my results that could be attributable to roundoff error even though m = 3.  What I had before is above the solid black line & below that line after eq (3) is what I have now for a series of 3 terms intead of 10.  What I had before the error is so large I have a hard time believing it is roundoff error.  Maybe someone can point out why?  What I have now I am happy with.

swapping_orders_of_operation.mw

@acer 

If you are surprised that S1 contains LerchPhi while S2 does not then you do not understand what active `sum` does as symbolic summation and what happens when `sum` and `int` return unevaluated (and why that can happen).

This is EXACTLY what I do not follow.  My understanding is 'sum' is NOT symbolic nor is 'int'.  So why did S1 & S2 not concur?  In both cases I am using both 'sum' & 'int', correct?  If I am wrong, why?

@acer 

This is the 4th Question by you in about a month on the broader topic of summation of trig expressions. (In one of them I showed you about a 1000-fold speedup for your float compuation, but I cannot tell whether you saw and digested it all.) The themes include distinguishing sum vs add vs Sum vs evalf(Sum(...)). It seems to me that you are carrying some misconceptions (possibly tacit).

You are correct.  I obviously have misconceptions, especially when I get results that contradict each other.  I am trying to grasp what is going on.  It is one thing to have command syntax issues.  It is quite something different when you get results which are not consistent.  That is why I question what is going on.

@acer 

I ran the code twice & got 2 different answers for S2 for n = 10 & I did not get ZERO for S1-S2.  How can roundoff account for this behavior?  So I am still confused.  It seems to converge to the correct value for higher values of n.  Why is it only S2 that exhibits this behavior & not any one of the other 3?  I will add another question to this.  Both S1 & S2 utilize the sum command, but the order of operaion is switched.  S1 has the LerchPhi function whereas S2 does not.  So this is not an issue between sum vs Sum.  This is fundamentally different.  This is why I did not include it with my other threads.  I hope you can enlighten me.

RUN #1:  swapping_orders_of_operation_roundoff.mw

RUN #2: swapping_orders_of_operation_roundoff2.mw

@acer 

If you had read carefully the question was actually different even though the MAPLE file had the same name.  If you read carefully there is a discrepancy of one of the results which I do not understand & your removed it so no one can comment on the discrepancy.  I am going to repost this & I would appreciate allowing others to comment on this problem.

@phil2 

Your explanation accounts for the results of equations (3) & (4), but does not address the results of (1) & (2) as far as I can tell.

@Preben Alsholm 

I like to use the test relation to double-check myself.  Now knowing the possible pitfalls maybe I can work myself around contradictory results.  My guess is I will run into this issue often.  If I run into something egregious I will post again.

THANX

@Preben Alsholm 

Let me surmise your statement so that I understand it correctly.  You are stating that constants that essentially have an infinite number of significant figures such as pi or 1/3 or sqrt(2) will cause problems.  So to circumvent those problems simply rename these values by some arbritratry variable such a c1?  This works as long as I remember what c1 represents?