@tomleslie 

I loaded the file from the wrong directory.  Sorting by magnitude is probably shat I want.  I made a couple of attempts & encounter the following error:

Error, sort: 2nd argument must be a function that always returns true or false

Download reconcile_solns.mw

My latest worksheet below seems to suggest that in the case of chek the series parameters m, a0, N, & tau have not been assigned values.  In the case of chek2 those parameters do have assigned values; hence, the solution characteristics are different.  It would be nice in the case of chek that the correct solutions can be obtained without having to assign parameter values beforehand.

Am I expecting too much?  If not, how can I achieve what I want?

reconcile_solns.mw

@acer 

I presume you are responsible for deleting a quetion I posted today trying to reconcile both analytical & numerical results on a solution that is relevant to this problem.  If you feel the question is too closely related to this posting then why do you not respond & place the results HERE?

The question is related to this solution, but the question is different from the original question on this posting.  The original question on this posts was trying to sort through the recursion errors.  After eventually wading through the MAPLE minutia I had results of which I wanted to reconcile.  That is a fundamentally different question.  Is it not?  If it is not you could have at least moved the question & responses to this posting & alerted me.

Do you have some guidelines for this website?  This unilateral deleting of questions is proving to be counterproductive.  I thought this website was to facilitate the use of MAPLE through inclusive dialog.  It is proving to be otherwise & very discouraging!!

I included links to my worksheets below.  It would be nice if you would let someone see if they can reconcile the 2.

analytic_solns.mw

numeric_solns.mw

@acer or anyone with MAPLE expertise

I think I possibly found a plausible reason for the discrepancy, but I am not sure how to test the case since MAPLE is not evaluating Q3.  Hopefully, your expertise in MAPLE can scheme of a test?

MAPLE could evaluate the Fourier series of the function that is associated with the Friedlander shockfront which is S5.  MAPLE could then sucessfully differentiate that series without a problem which is Q1.  Q3 is actually Q1 in principle, but no differentiation takes place.  Q3 is the direct summation of the expression associated with the differentiation of S5.  I hope you can follow me on this, because when I read this it confuses the HELL out of me.  I have included a worksheet which I hope facilitates understanding what I am trying to convey.

C(k) are the Fourier coefficients of the Friedlander waveform.  How C(k) is evaluated is included in the worksheet.  The nature of the Friedlander function is that it never actually = ZERO as x or t -->infinity.  It gets VERY close, but not actually ZERO.  So differentiating the series has to account for the miniscule jump from the final value at the end of the time record to ZERO.  MAPLE handles this OK as indicated by Q1, but in the case of Q3 it does not.

I am unsure in constructing some type of test in MAPLE to see if this is the problem.  I would think MAPLE would have trouble evaluating Q2 due to this discontinuity, but it apparently does not.  Do any of you have ideas on this?

inconsistent_results.mw

@tomleslie 

Your example is NOT bounded it goes to infinity with k-->infinity.  This does not satisfy the criterion I mentioned.  My problem does meet this criteron.

Tom,

You could not have provided a WORSE example other than the exponential function itself.  Please, can MAPLE handle my problem or NOT?

I do not wish to debate MATHEMATICS nor PARSE language in our postings.  I want to know why the apparent discrepancy.  You are not addressing this.

You are pigeonholing me into having to rephrase my question & posting it again.  @acer has busted my ASS for doing this.  But, I am no longer getting anything productive on this question.

@acer 

I no longer get the recursion error or the warning of lost solutions.  However, the form in which the solution is presented I do not know how to interpret.  Any guidance on this?

solved.mw

@tomleslie 

Your assertion is that since Maple can compute sum(f(k,x), k=1..m), as a closed form, it *must* be able to compute sum(C(k)*f(k,x), k=1..m) as a closed form.

I take it that you are saying in my case there is no analytic representation of what I am looking at?  If you look closely at my earlier worksheet you will find that S5 & Q1 is evaluated; whereas, Q3 is not.  Q1 is the derivative of S5 & so is Q3 which you demonstrated in the worksheet you supplied, but with the "INERT" Sum.  If both S5 & Q1 (my worksheet) is closed form then why would NOT Q3 be also?  This makes NO sense?

You can argue that the "INERT" Sum is more suitable tool for my application, but that does not explain the inconsistency that I am pointing out. 

I'll set a simple example -suppose f(k,x)=1 for all k, x. Your assertion is now that Maple should be able to calculate sum(C(k), k=1..m) for any C(k): ie all sums have closed forms! Get real

NEVER did I imply for all C(k).  I believe I stated in my case C(k) is well behaved + analytical on top of that.  I could be wrong, but my impression if C(k) is bounded & smooth (implies analytic) then the summation as long as the accompanying function such as sin(kx/T) is also analytic.  If not, can you provide an example aside from my case?

Is there anyone else able to offer up a viable explanation?  @acer I hope you can take another shot at this.  I will concede that maybe "INERT" Sum the is more appropriate, but that is not question I am asking.

@acer 

@tsunamiBTP In your latest "badws.mw" attachment S5 is assigned an expression that contains this, where Ck is a complicated expression in terms of unassigned names K, N, and k.

        Sum(Ck*sin(2*Pi*k*x/T), k = 1 .. m)

Since that is a call to inert Sum, Maple doesn't try to compute the summation in any kind of closed form. The inert Sum is a placeholder for the summation.

I conceded this fact in in my reply .  In my haste I copied & pasted betweeen 2 worksheets a bit carelessly.  My reply provides a link to a worksheet which employs  the  "ACTIVE" sum"  to compute S5 & S6 versus Q3 & Q4.  Q3 & Q4 are derivatives of S5 & S6 written out long hand using the  "ACTIVE" sum".  S5 & S6 can be evaluated, but not Q3 & Q4. 

Why do you believe so ardently that symbolic summation of the derivative of a complicated multivariate expression should always be as easily computable as the symbolic summation of the expression itself?

Why would it not be?  The coefficient, Ck, is not differentiable with respect to x.  Let's remove Ck & repeat the summation.  MAPLE does not seem to have any difficulty with this?  The results are in the link below:

Download ignore_Ck.mw

Without Ck all of the harmonics do have the same constant coefficient of UNITY.  This makes matter easier because simplification can be done.  Nonetheless, the presence of Ck with no dependence on the independent variable, x, should not render the expression unsolvable?  If Ck did not decay with respect to the frequency variable, k, then I concede the expression is unevaluatable.  Not only is Ck well behaved it is analytical.  So shall be the derivative.

So can MAPLE handle this situation or NOT?  I would be disappointed if it cannot!!!!

I presume alot of people on this website are volunteers.  Can a MAPLESOFT employee answer this?

@acer 

Do you have a reason to think it should be possible?

YES, it should be possible.  I have done it with the most simplistic of generalized inputs such as the UNIT STEP function.  I included a link for those results below.  What I have changed is a modification to the input function to be a UNIT TRIANGLE waveform instead of a UNIT STEP.  This causes a change in the Fourier coefficients, but the overall eigenfuntion of sin(2*pi*k/T*x) does not change & that is true for the derivative.  So my expectations that the roots of the derivative will shift to lower values of y, but still be solvable as in the case for the UNIT STEP input.

My response is a bit cryptic to keep matters short.  There is ALOT of underlying details I can provide if necessary.  What I am looking for is this shift in the roots given the change in the input stimulus.  I hope you follow me.  The actual waveform that I am trying to resolve is even more complicated & it is associated with shockwave physics.  I alluded to this in another posting.  The solutions to that in principle should be solvable analytically (it might be messy).  I actusally am only interested in the first 2 or 3 solutions.

trig_series_solns.mw

The solutions for the above link are presented in both eq's 9 & 13. 

BTW: The link below presents solutions for both the UNIT TRIANGLE & UNIT STEP numerically.  You actually contributed to helping me with that in working with the fsolve command.  The numerical results appear to be correct.  However, I now am pursuing the analytic solutions because there is a BONE of CONTENTION on the rate of convergence & the final value of that convergence, especially for the shockwave case.

numerical_solutions.mw

If you feel that the solutions cannot be attained analytically given my approach, could it be done by using the limit as m-->infinity?  I have not used tha @limit commands in MAPLE.

I seem to have eliminated the "recursion" error, but now I am encountering "Warning, solutions may have been lost".  Does anyone have any suggestions?  Do I need to restrict the domain for y even further?

Download 2_many_levels_of_recursion.mw

@tomleslie 

You are correct.  I simply cut & paste from one worksheet to another a bit carelessly.  My question is STILL VALID!

See the link below for S5 & S6 versus Q3 & Q4.  That is my worksheet.  Q3 & Q4 are derivatives of S5 & S6 written out long hand using the  "ACTIVE" sum".  S5 & S6 can be evaluated, but not Q3 & Q4.  These are the inconsistencies that are MADDENING.

Note that Q1 & Q2 are also derivatives of S5 & S6 by using the partial derivative.  These derivatives do exist.  Can you or someone else explain this?

inconsistent_results.mw

@acer 

@tsunamiBTP Yes, it is unhelpful and awkward that the Expression Pallete has the entry for sum on it. That is probably the worst choice for the palette, of the three under discussion. The decision was likely made by people who did not properly understand the significance and the importance of getting it just right.

OK, but what about the specific question asked:

on this particular demonstration why can the computer evaluate S5 & S6 using the "ACTIVE" sum; whereas, it cannot be done with Q5 & Q6?

badws.mw

@acer 

@tomleslie 

WOW!  1st off I am happy for your responses even though they may be a bit SHARP.  Nonetheless, as pointed out Sum, sum, vs add all have different functions.  This is why I have explored in past questions comparisons between the results.  What exists in the GUI palette is the "ACTIVE" sum?  Whereas, @tomleslie uses the "INERT" Sum to achieve what I was pursuing in short order.  This is VERY confusing to the end user, especially to anyone who is being introduced to MAPLE.  I have been working with a particular issue considering convergence of the Fourier series representation of a particular waveform that is associated with shockwave physics.  I have been working this problem for a couple months & I still stumble onto confusing results when I attempt to work with all 3 commands.  Call me a bit over conservative in attempting to confirm results among all 3 different commands, but it is my way to convince myself I have results I understand.  When I cannot make that confirmation I post to this website in an effort for some help.

So below I have made additions to the worksheet @tomleslie provided.  You will see that I attempt to use "ACTIVE" sum to evaluate what appears to be the derivatives of both S5 & S6.  In doing so my computer chokes on the results & MAPLE crashes.  This is a problem since the "ACTIVE" sum is the 1st choice of an unwitting user to select since it appears in the GUI palette.

So my question on this particular demonstration why can the computer evaluate S5 & S6 using the "ACTIVE" sum; whereas, it cannot be done with Q5 & Q6?

badws.mw

I will add that solving for the roots of the series seems to require the "ACTIVE" sum as opposed to the "INERT" Sum.  I posted a question on this issue earlier this week & it got deleted.  I will likely repost that question & I presume it will NOT be deleted?  I hope now you appreciate the frustration I have been experiencing on this.  This is somewhat a manifestation of the software programming of MAPLE.  This type of confusion should have been foreseen.  The HELP menu is not all that effective at demonstrating these differences in my opinion.

I hope you can address the specific question:

on this particular demonstration why can the computer evaluate S5 & S6 using the "ACTIVE" sum; whereas, it cannot be done with Q5 & Q6?

I was hoping for some input, but none so far.  If there is any more info I should provide let me know.  I really need some help on avoiding the convert command I think.

I am not sure, but maybe I found the way to execute conversion of the "INERT" form to find the solutions.  Nonetheless, interpretation of the output is still a question.  Is the _Z7~ an integer multiple from 0 to infinity?  In otherwords, the solutions are all integer multiples of K*N*tau/4/n?  The solutions for Q7 & Q9 are 4 distinct solutions, but they are multiples of K*N*tau/4/n.

If anyone can guide me to an appropriate output that would be great.  Moreover, I employed the convert(...,sum) command to get the solutions.  Can I avoid convert altogether to get the solutions?  I ask this because if the coefficients of the series become dependent on k instead of being a constant value of 4/T then converting the series becomes computationally sluggish.  An example of this situation is in the 2nd weblink for the variable Q8.  I am expecting BAD news on this issue, but I know there are alot of MAPLE GURUS on this website that possibly can circumvent this.  I have my fingers crossed.

lost_solutions.mw

convert_to_sum.mw