I get the following error when working with the "INERT" Sum?

Warning, solutions may have been lost

I do not get it when working with the "ACTIVE" sum.  I tried the AllSolutions option, but still get the same message.  How can I get the proper output working with the "INERT" form?

lost_solutions.mw

@acer 

This is an addendum to the previous worksheet add_vs_sum_vs_Sum.mw.  See after the 2^nd restart.

No matter how I look at this I can get sum & add to concur, but I cannot get your improvised technique to concur with earlier results.

@acer 

See the results in the link below.  I show concurrence between sum vs add, but not Sum vs add.  I hope I have not reversed sum & Sum.  Nonetheless, check out results (8) & (9).  Those results do not even account for the integral.  So if I am correct your improvised technique to circumvent memory issues will not necessarily provide EXACT equivalence.  I wish we could talk in person because I could then show you what I want to achieve.  As it is I try to confine the scope of my posted questions to a single issue.  Conveying the overall goal is a bit tough to do via this forum.  Unfortunately these inconsistencies with MAPLE are impeding my progress.

If there is a way to symbolically confirm the equality of all 3 commands that would be helpful.  I am sure at some point in time all of this had to be validated, but in my case they appear APPROXIMATELY the same, not EXACTLY the same.  These 2 distinctions can be important.

Like I said before I never knew these 3 commands existed before all of this.  I only knew of sum which is on the expression palette.   So to the average user this is all very conflicting.

add_vs_sum_vs_Sum.mw

@acer 

I will reiterate:

I am not sure if I should place this posting here or in my other questions of sum vs add or sum vs Sum.  I will try here 1^st.  My results in the link below show concurrence between add & sum commands (see result (8)), and the difference in their computation demands.  In this posting we circumvent the computation demands of sum via use of Sum & add.with a trick presented by @acer.  Unfortunately, after appying this trick the concurrence between add& sum does not seem to be valid any longer (see result (11)).  Result (12) shows that they are nearly identical numerically.  Why are they no longer EXACTLY identical?  My guess is the application of the integral in S1.  However, result (13) shows the integral relation between the sin(x) & cos(x) which is EXACT.

Am I expecting too much from MAPLE?  I have always had the impression that MAPLE is quite superior at handling these identities so I would expect concurrence between S9 & test.  Perhaps I am bucking against the INERT vs ACTIVE commands once again?

See my latest results as posted on:

https://www.mapleprimes.com/questions/223997-MAPLE-Crashing-Due-To-Memory#comment246461

If MAPLE cannont recognize this I think evaluating it numerically maybe can be sufficient, but that does NOT satisfy the 2 expressions are UNIVERSALLY equivalent which they are.  Numerical evaluation might support local approximation of a nonlinear function, but does not show GLOBAL or UNIVERSAL equivalence.  So the fact that MAPLE crashes seems to suggest it is attempting to evaluate the difference & does not recognize the difference should be =0.

@acer 

x vs t I should have realized that.  It BITES me too frequently.

For this particular comparison normal is adequate, and simplify should be too. The trig subterms have similar form, but the terms are structurally different arithmetically (ie. wrt addition, multiplication, and integer powers). Try it with much smaller m (which gets assigned in two places in your sheet) to see what I mean

Nonetheless, I dropped m down to 5 & I still get the message "Length of output exceeds limit of 1000000":  When I attempt to use the normal command the KERNAL crashes.  My results are in the link.  Any other way to avoid computational limitations?

results_computational_expense.mw

@acer 

I am not sure if I should place this posting here or in my other questions of sum vs add or sum vs Sum.  I will try here 1^st.  My results in the link below show concurrence between add & sum commands (see result (8)), and the difference in their computation demands.  In this posting we circumvent the computation demands of sum via use of Sum & add.with a trick presented by @acer.  Unfortunately, after appying this trick the concurrence between add & sum does not seem to be valid any longer (see result (11)).  Result (12) shows that they are nearly identical numerically.  Why are they no longer EXACTLY identical?  My guess is the application of the integral in S1.  However, result (13) shows the integral relation between the sin(x) & cos(x) which is EXACT.

Am I expecting too much from MAPLE?  I have always had the impression that MAPLE is quite superior at handling these identities so I would expect concurrence between S9 & test.  Perhaps I am bucking against the INERT vs ACTIVE commands once again?

tying_up_loose_ends.mw

In the dropdown menu for the Format tab @the top of the MAPLE worksheet there is a Convert to option.  Choose to Plain Test.  This would have eliminated some confusion as to what the symbolic expressions in the expression palette convert to in command text form.

@acer 

OK, I translated your text based commands into something more symbolic which for me is a bit more compact.  I took some liberties expecially with the map command.  My end result concurs with yours, but I would like you to comment if anything might BITE me down the road due to how I interpreted your method into mine
 

Download more_int_sum_add.mw

.

@acer 

sum=black Sigma, while Sum=gray Sigma

I thought it was the reverse, but I checked & what you say above is correct.  Unless MAPLE 12 can toggle between the 2 I could swear what was on the Expression palette was Sum.  I will try to be conscientious of which is which.

I am still working with your latest response to understand what is happening.

@acer 

I am sorting through your worksheet & what you have done is REMARKABLE, but I do not understand the distinction from the folloiwing:

Download the_distinction.mw

It is clear your text command method works successfully while the symbolic form HOGS up the computer.  Reading your text format I interpret as being the same thing as the symbolic expression.  The int corresponds with the symbolic integral?  The Sum corresponds with the symbolic sigma?  Moreover, the order of operations is the same between the 2.  So this is not an issue of INERT vs ACTIVE as you have pointed out in the past, correct? 

I am still reading up about the map command, but what is above seems to be the difference & I do not know why.  This does not have anything to do with compiling which you briefly mentioned?  Does it take the compiler an extreme effort to interpret the symbolic form to the text command form that you provided?  Of course, this is assuming your text based command is the same as the symbolic form.

@acer or anyone else

OK, so I am posting this question here 1st because it is related, but a different problem is encountered.  So I am confused when or when I should not post a NEW question.  Nonetheless, I will try here 1st & hopefully get something back within 24 hours?

I believe I have produced decent numerical results given you enlightening me on the "working precision".  I suppose I should be content with that, but now examining this symbollically I do not have to worry about "working precision", true?  So below is my link on my recent effort on swapping the order of operations.  The problem I encounter is that MAPLE crashes due to the demand on memory.  So I reduced the number of terms in the series to reduce computational demand.  Oh, by the way, I did attempt to leave m as undefined which also resulted in MAPLE crashing.

I believe I understand as to why the swap would require greater demand on memory since execution of the integral of the series requires integration of each & every term of the series; whereas, the other way the integral is only executed once.  I think that is why.  I am posting this because maybe I do not see this correctly & someone might suggest how to avoid the memory problem.

Thanks for any feedback

swapping_orders_of_operation2.mw

@acer 

https://www.mapleprimes.com/questions/223965-Add--Vs-Sum-Command#comment246299

I examined the distinction between add & sum commands & also included the Sum command as well.  I am a little bit confused by your statement below:

You've also ignored other (good where applicable, but not quite as good as compiled add)  suggestions to utilize evalf(Sum(...)) accelarated float summation (in the case of diminishing terms). This involves using Sum instead of sum.

My results seem to show a severe computation penalty of using Sum as opposed to sum.  So I am still a bit confused.  Maybe there is another way to spin my results?

The link below for the sake of archiving purposes demonstrates the distinction between add & sum & Sum.  Numerically they yield almost the same result to within 10^-10.  However, the computation expense of Sum is immense.  Maybe this will be useful knowledge to someone in the future.  I learned the hard way by experimenting with all 3 commands.

NOTE: If m is assigned a value instead of left undefined then the computation expense for Sum is reduced considerably, but still the expense dwarfs the other 2.

sum_vs_add.mw

@Carl Love 

I think the reason my computer was BALKING is because of the add command?  I assigned values to all of the variables in the function & then used evalf to check the difference in significant figures & it was on the order of 10^-10 & that was allowing m=10000.  So attempting to compare results symbolically is NOT the way to go?

@Carl Love 

Below is a link to a modified version of my original file attempting to define metrics to assess the differences between add & sum.  I am looking at the CPU time & memory & clearly the Sum command is the most expensive.  However, when I attempt to assess the equality between the commands I run into trouble with my computer crashing or simply hanging.  You can see after (7) I attempt to compare S9 to S7 & S10 to S8.  When I compare S5 to S7 MAPLE quits altogether.  I presume I am running out of memory.  I reduced m from 10000 to 10 & still the computer produces no results.

Can anyone else generate meaningful output & if so how?

sum_vs_add.mw