@tomleslie 

I noticed that you titled your worksheets by "Parseval".  It is my understanding that Parseval based his theorem on square integrable functions which I guess is a larger class of functions than just periodic.  Rayleigh at a later date showed that for periodic functions that the summation of the square of the Fourier coefficients approaches the integral of the periodic function squared over the span of 1 fundamental period of oscillation.  Is this correct?  What is your understanding?

@tomleslie 

In both cases, I would suggest that you be a little more careful about the definition of the 'period' of the function.

OK, this is GOOD.  Now I can reconcile my original worksheet hopefully.

@tomleslie 

OK, I got the Orthogonal Expansion package to work in the link at the bottom (it is a NICE toolkit).  I worked both CASE 1 & CASE 2.  In CASE 1 the integral & summation quantities converge to the same value as you & I demonstrated.  However, CASE 2 does not.  This is the same behavior I observed in my Rayleighs_identity.mw worksheet.  NOTE that CASE 2 is neither an even or odd function.  It simply repeats itself for every period of T=1.  I am perplexed in this convergence discrepancy.  I hope you have an explanation.  Regardless of this discrepancy the Fourier series does seem to approximate the actual function reasonably well?

use_of_orthogonal_series_toolbox.mw

@tomleslie 

Last Point

Some time ago I attempted to use the OrthogonalExpansions toolbox per someone else's suggestion.  I am not sure it works with MAPLE 12.  It does look like a nice package to use if I could get it to work.

The OrthogonalExpansions package was created in Maple 13, but (on a quick examination of its code) I would be very, very surprised if it didn't work in Maple 12. It would take all of 10 minutes to download/install and test a few of the examples from its help pages. If they work then you are almost certainly "good to go". Then you can actually run the worksheet(s) I supplied. This seems like a such a simple process, I am completely at a loss to know why you haven't  tried it!

I will try it again on my LAPTOP.  Hopefully, I will have some luck.  I think without any elaboration is that my ZEROTH order value for Ck is not correct.  That would certainly cause problems in converging to the proper value.  All of the other Ck values do converge to finite value.  Maybe the OrthogonalExpansions package might give me a clue.

@tomleslie 

1: You changed the observation period, T, for the function.  Nonetheless, I made those changes in my worksheet & my results concur with yours for CASE 1, but not CASE 2.  So I am still in the same predicament regarding this discrepancy.

2.  Some time ago I attempted to use the OrthogonalExpansions toolbox per someone else's suggestion.  I am not sure it works with MAPLE 12.  It does look like a nice package to use if I could get it to work.

The link has my worsheet modified according to the change you had in yours.  So I am still unsure of my error in CASE 2.

Rayleighs_identity.mw

@tomleslie 

Thanks.  Boy we can get MYOPIC sometimes & never see the forest for the trees.

@tomleslie 

You are a little late.  I already got my worksheet to work.  This malicious content in banter is a complete TURNOFF.  I have begun to ignore your efforts.  This is VERY UNFORTUNATE because I held this website in pretty high regard.  That has now been soiled.  I think you have lost the spirit & purpose of this website and have interjected your attitudes in your responses.

Maybe in the future if there are any future exchanges it will be more productive.  This was not & that includes @acer responses.  By the way, I noticed all of his content has been deleted.  I wonder why?

@acer 

You call my reply above impatient. I think I've been far more patient than is merited by your continued disregard for every part of my answers.

I may move all the comments on this Answer that are not written by me to the main Question, and then delete all I've written here. I thought I'd take one last shot. But now I believe that you are a full fledged math crank and will never really listen to advice or attempt to understand even basic explanations.

I have NO IDEA what you mean by this statement.  If "math crank" is derogatory then you are OUT OF LINE.  If you mean AMATEUR then YES you are CORRECT.  I did not think you had to have a MATH PhD to participate on this website.

This website I thought was intended to promote & facilitate the use of MAPLE.  It does not help to BROWBEAT users.  Between you & Tom Leslie you are discouraging the use of this website by users less experienced than either of you.  I do not think MAPLESOFT would appreciate this behavior on a website they sponsor.

@acer 

I applied the following per your suggestions (more appropriately my interpretation of your suggestions):

None of my code for this topic ever did what you've now tried. Instead, my earlier responses to address this problem with memory resources used unapply to create a procedure, so that the only things being added up were floating-point numbers and not any symbolic addends (containing trig calls, etc).

I have what I think you refer to as a procedure for S5 through S10.

You should add up m=10000 floating-point numbers (each computed from evaluating the generic subterm at some specific integer k and some floating-point value for x). As seen above in my Answer, that can even be done fast and leanly under evalhf. But even if you don't want to use evalhf mode, it is far less resource consuming to add up only the individual floating-point values for each k from 1 to m=10000 for each given floating-point x value.

I then inserted S7(100000,0.00002) into the RootFinding:-Analytic command.

My result: Error, (in RootFinding:-Analytic) the function, 0, should be non-constant.

Now if you could point out what you are trying to tell me in the code without condescending remarks that would be good:

RootFinding_Analytic_b.mw

@tomleslie 

Your code flat out is not running in MAPLE 12.  I get errors all over the place.  I take it if you won't convert it you can allow someone else to?

@acer 

Your latest problem with running out of memory, as in several earlier posts on the same topic and theme, is that you are calling sum (or add) when m has been assigned a large postive integer value but x remains unassigned. That is a crazy thing to do. It is wholly unnecessary to form the explicit sum of the m symbolic terms. That's why you now run out of memory, because the thing you pass to RootFinding:-Analytic is a huge expression of m symbolic terms.

I will try to interpret your statement above:

Are you saying I need to feed to the RootFinding:-Analytic command an initial value for x?  I tried to do as such, but nothing worked!  I can try again.  If this is what you are saying it would have been nice to say as such instead of your impatient response.

AGAIN, you assume FAR TOO MUCH!  If you are saying something else I suggest you reword & make matters more explicit & point out what in the code is WRONG!

This is the error I received after assigning a value to x:

Error, invalid input: diff received 0.2e-4, which is not valid for its 2nd argument

@tomleslie 

I ran your code & I get errors on CodeTools & RootFinding.  Can you convert to MAPLE 12?

Error, Usage is not a command in the CodeTools package

Error, (in RootFinding:-Analytic) the option for specifying the real range is: 're=x1..x2', where x1 and x2 are real constants.

I looked at the output of your posting & the smallest REAL root was 0.0001999700039 which corresponds to 10000 terms in the series.  I do not see any output for 100000 terms.  So I still do not know if what you have submitted will reduce memory demands to the point I can get meaningful results.

@acer 

@tsunamiBTP It seems pointless for me to bother to fix it for you or explain it, since you continue to do every single thing I've advised against.

I used the RootFinding command per your example?  You know the inner details of MAPLE, I do not?  Even if I modify the code you provide that does not mean I will not encounter another problem.

You assume too much!!!  I say this because you are assuming you conveyed your message or point effectively over the web & not in person.  You do not know that!  I can use either add or Sum & the problem persists.  Is that what you are pointing out?  Explain

@acer 

I will post the question here 1st.  If the thread is dead & I get no response I will resubmit in a new post.  The problem is similar to seeking_the_limit_ac_M12.mw, but the question is different.  My link below includes the use of the RootFinding-Analytic command to find the roots of the series in question.  However, as I continue to increase m (number of terms in the series) I attempt to narrow the field in which the solutions will exist.  As you might expect the demand on memory increases with m.  Narrowing the field of plausible solutions should help counter this, but I still am running out of memory.  I attempted to restrict the solutions to lie only on the Real axis, but got an error.

Is there another command I should use or is there a better way to reduce the demands on memory for increasing m?

RootFinding_Analytic.mw

@acer @tomleslie

What about the limit or Limit  commands?  The method we used to find the limit of the series to within 5 sig figs was a bit piecemeal.  Would the limit or Limit  commands be more appropriate?  I made a few attempts without success.  Do either of you have a way of making those commands work or are they not useful in this case?

ADDITIONAL COMMENT:  The series that we are dealing with has a peak value that continually shifts towards x=0 as k-->infinity.  So seeking the peak value also requires iteration on x for each k.  So as I stated above our current solution is doing this piecemeal.  It would be nice if this could all be done in 1 step.  So I do not know if the limit or Limit  commands can handle this situation where the limits on 2 variables need to be accounted for.  My code writing skills with MAPLE are not up to the task of accomplishing this at this time.  I might be able to do it in MATLAB, but even then I would likely encounter a bunch of debugging