@acer 

 I'd counter that you might not be reading all the responses with enough attention to what the thrust might be.

In the thread that was originally about fsolve vs Rootfinding I did not recognize the difference in the add vs sum.  Again, the subtlties in such commands are not always evident to the questioner.  You demonstrated effectively between fsolve & RootFinding, but to expect me as the questioner to recognize the difference between add vs sum, it simply did not happen in this instance.

I posted a new question on the issue of add vs sum & hopefully it will not be deleted.

@acer 

I guess I did employ the add command.  I guess I assumed the add & sum were one & the same.  I do not see anywhere that you distinguished between the 2 other than use the command in defining S1 in your code.  The issue on that thread was the difference between fsolve vs RootFinding so the underlying subtleties between add & sum were not discussed so I would have never known the difference without you directly mentioning it or that I stumble upon some discrepancy in future results.

This is where your responses seem a bit terse because you are assuming the person you are addressing has this underlying knowledge & that is rarely the case; hence, the need for the MAPLEPrimes question forum.  I think I will have some follow on questions about this distinction & will post a NEW question at that time & hopefully it will not be deleted by you.

@acer 

In my Answer to a related Question of yours (Dec 15, 2017) I showed you how to obtain something like a 500-1000 fold speedup in evaluating such summations. That question also involved rootfinding, but the essence of accelerating the summations is the same. You never responded to my Answer, and in the interim have made several other postings about performance of related summations -- without any attempt to utilize my performance suggestion.  That involved using add instead of sum.

I remember this discussion, but fail to see your point on summation.  If I recall I was solving for the roots of a derivative of a series which in itself is a series as well.  Once the roots are determined then evaluate the original series @the root location.  You showed me the rootfinder tool & how much faster it was than the conventional approach I was using.  It indeed was immensely faster as you state above.  However, evaluating a series as a function of some arbitrary variable I fail to see how the rootfinder tool can do this & then use it to compare with another expression form of the same series?  I suppose you could argue if the roots of one expression matches those of another then the 2 expressions are identical?  I can see the utility of this argument for comparing some intricale polynomial, but I am not sure about a series or all functions in general?

If this is what you were trying to point out I did not get that message.  Maybe you have an example?  Regarding the add command I will have to give that a try.  I do not recall attempting that operation.

@acer 

You are correct in that not all of the output gets into the MAPLEPrimes display below.  That is a bit annoying.  Anyway, did the unapply command UNDO what you identify as a PROCEDURE which was executed by equation (3)?  I see now that T1(m) is now effectively Q1 & I presume the same is true for T2(m) = Q2.

So do I execute the PROCEDURE 1st & then UNDO it via unapply OR simply invoke the unapply command exclusively?

Download is_command.mw

@acer 

I notice that you continue to ignore the advice -- made for several of your earliest (of many) Questions in this long saga -- that:

1) inert `Sum` may be more suitable than active `sum` to your overall investigations and more particularly your attempts at symbolic verification

NO, I am not ignoring anything.  I include both INERT & ACTIVE sums, for my sake, to indicate that indeed the 2 produce the same results, but the 2 commands do behave differently.  KEEP IN MIND that you know the inner working details of MAPLE.  I do NOT.  Before all of this work I did not know about INERT vs ACTIVE.  I picked up MAPLE as a tool for research purposes & have learned it only through trial & error & interacting within MAPLEPrimes.  I have had no formal classes or training with using MAPLE code.

2) `add` (under evalhf, or Compiled) would get far better performance than `sum` and likely exhibit less roundoff in the case that `sum` or `simplify` or `combine` produced trig terms with large rationals.

This I will check out.

Regarding the issue in question I am working with what you provided to digest what is occurring & likely will have follow questions.

@Preben Alsholm 

What is this T1(7) you speak of?  Nonetheless, I removed d/dt(S11) & still everything remains FALSE.  Can you please modify what I have below to generate a TRUE result?  Your analagous or parallel code examples do not seem to yield anything useful to my situation.  Your explanations are not being interpreted well.

NOTE that m is now included with both T1 & T2 so again FALSE results are generated.

Download is_command.mw

@Preben Alsholm 

I am still experiencing problems.

Download is_command.mw

@Kitonum 

It seems to work now.  Hopefully, it will not happen again.  I probably had some typo

@acer 

Below are my results for computing a series in 3 different ways:

S11 & S12 vs S13 & S14 vs integrate X & Y.

Now, am I interpreting the results correctly?  The reason I ask is that I am not confident that I am reinitializing my reference times & memory usage appropriately.

1) The 1st method requires much more computation time.

2) The first 2 methods require the same amount of memory while the 3rd method requires slightly more.

Download CPU_memory_usage.mw

@acer 

Is there some simple modification to get CPU & memory usage?  See below:

Maple Worksheet - Error

Failed to load the worksheet /maplenet/convert/CPU_&_memopry_usage.mw .
 

Download CPU_&_memopry_usage.mw

@acer 

OK, I am showing the error discrepancy for a small rang for values of n from 1 to 100.  I then recompute the values with  a greater number of sig figs for the evalf command & results are well behaved.  My suspicion is that the sin term in the denominator is the culprit sense I am evaluating the integral from T/(4n) to 0.  The value of T/(4/n) is a solution to the roots of (7).

How to establish the level of sig figs a priori I still do not know.  Maybe you have some insight?  It almost seems the form of the function within evalf must be known.  So some arbitrary function of not well understood behavior will wreak havoc?

divergent_behavior.mw

@acer 

OK I will anticipate your advise

@acer 

Is there a good rule of thumb in choosing the precision & how to apply it?  Let's assume I do not realize that the expressions I was analyzing should be equivalent.  I would then conclude by the results that the expressions are NOT equivalent.  However, if I had picked a particular value of n where the expressions agreed I would arrive at an opposite conclusion.  So I need to know how far I need to evaluate the sig figs.  50 sig figs seems a bit absurd in a practical sense, but you have demonstrated otherwise.

I appreciate you pointing this out.  Now I need to wrap my head around the issue.

@acer 

Hi acer.

I posted the question & then took my flash drive home to look at the problem closer & it occurred to me that you pointed out a ROUNDOFF issue in the past.  At that time I failed to grasp that issue because the discrepancy was so LARGE.  My impression has been that ROUNDOFF issues affect significant figures accuracy to some 10^-x order.  When I see errors on the order of 10^+x I think something else must be the culprit.  Now it manifested itself again in a slightly different situation.  The odd thing is that the discrepancy occurs only within a band of n values.  I think on the previous question you pointed out that the ROUNDOFF was large for small values of n & diminished for higher values of n.

In this instance good results for small & large values of n, but not so much for the narrow region for n<7<100.  This almost seems to be some issue of a singularity associated with n.  Anyway, I will attempt to apply your suggestions, but I am sure I will have follow up questions on this.

@vv WOW, that was quite a workaround which is not entirely intuitive, but I believe is correct.  It certainly was not what I was expecting.

I'll attach my worksheet for any future reference to such a situation.  What makes the evaluation work is given in the last line where the subs command is invoked.

Download evaluating_integral.mw