Skip to main content
A
Annesofieoe1-Visitor
1-Visitor
October 8, 2019
Question

Document stops calculating

  • October 8, 2019
  • 8 replies
  • 3563 views
Hi,
Our issue is that some of our Mathcad Prime sheets stops being able to calculate – especially when we are using the program for calculating Fourierseries/-integrals. The documents work just fine when we enter the calculations at first, but when closed and reopened it does not work anymore.
We have tried different settings in the “calculate” menu, but we haven’t been able to fix the problem.
I have linked to a document, that won’t calculate anymore.

Thank you in advantage.
 

8 replies

V
ValeryOchkov24-Ruby IV
24-Ruby IV
October 8, 2019

See please the Forurier series on Mathcad Calculation server

http://twt.mpei.ac.ru/MCS/Worksheets/Fourier.xmcd

May be it is help for you

L
LucMeekes23-Emerald IV
23-Emerald IV
October 8, 2019

I don't see the problem. But that could be due to me using Prime Express 4.0 (Express does not support programming nor symbolics.) but all calculation results are shown....

 

Luc

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019
@LucMeekes wrote:

I don't see the problem. But that could be due to me using Prime Express 4.0 (Express does not support programming nor symbolics.) but all calculation results are shown....

 

Luc

This is because on opening a Prime document you see the results which were calculated before saving the sheet as these are stored within the file. This is also the reason why you can use Express as a reader for files using the "advanced" features not available in Express.

The problem seems to occur when you try to recalculate the sheet (either on purpose or because you change some input data).

I tried in P4 and P5 and the first symbolic calculation of a.n did not stop - yellow dot forever.

Curious effect: When I tried to add "assume, n=integer" I got an error as of wrong syntax of the assume modifier.

 

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019

What exactly do you mean with "won’t calculate anymore." ?

When I open your sheet and try to recalculate it it starts calculating but the first symbolic evaluation (calculation of a.n) seems to run forever. In fact its still calculating while I write these lines.

Is the erroneous effect you are talking about?

I could open your sheet with Prime 4, so I supposed you created it with this version.

 

-
-MFra-21-Topaz II
21-Topaz II
October 8, 2019

Hi Annesofieoe,

Indexing is incorrect (see photo). You should use the appropriate equality operators (see photo).

indicizzazione.jpg

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019
@-MFra- wrote:

Hi Annesofieoe,

Indexing is incorrect (see photo). You should use the appropriate equality operators (see photo).

I agree that the boolean equal sign should be used when just writing down the general formula (using Prime not for calculating but just an equation editor). This should be done to avoid the red error and is just a cosmetic embellishment.

 

But it would be simply wrong to use a vector/matrix index for a.n. After all there is no range n defined (so you would get an error) and obviously the result is needed not numerically but dependent on n.

 

An improvement would be to use a(n):=... instead of a.n:=..., turning a into function dependent on n.

That way a(n) and b(n) could be used in the sum of the following definition of f(x) instead of copying and pasting the results of the prior calculations.

 

Further improvement could be when it comes to plotting. In the original sheet different functions g(x) and h(x) are defined just to get the plot. This could be done a bit easier using just 1 function:

clipboard_image_0.png

 

But all of the above does not address the recalculation problem which was reported here. I am not sure if its a bug in Prime 4 which makes the sheet unusable for symbolic calculations and if its fixed in later version or if its something completely else. After all when I stop the calculation, add some symbolic evaluations in front and recalc, the new regions are evaluated correctly symbolically and then the program again hangs at the calculation of a.n. Not sure whats going on here but at least I can confirm a problem with that sheet.

 

 

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019

Another observation:

 

I retyped the expression myself in front of the problematic region, stopped and restarted calculation and the region evaluated correctly. I had just used 5/2 instead of 2.5 to avoid the symbolics switching in float mode.

I copied that region (the one I just typed myself) and changed the 5/2 to 2.5 and now this newly typed region would again refuse to finish calculation.

clipboard_image_0.png

Still no idea whats going on here and why the symbolic float mode seems to be damaged in this file.

I have not tried but I guess when I start a perfectly new sheet and type the definitions of L, f.1, f.2 and a.n it would work OK, even with 2.5 instead of 5/2.

 

EDIT: It seems definitely to have to do with the float mode. When I add "float,3" in my (as far working) first region, it does not finish calculating after a recalc attempt.

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019

Last observation (I'm out of ideas)

 

I retyped the essential definitions in Prime 4 and a.n calculated flawless.

I saved the sheet, closed P4 and then reopened the sheet in P4 again - and the region a.n would not calculate when I let the sheet recalculate.

 

Now I did the very same with Prime 5 - retyped the few regions from anew in Prime 5, saved, reopend ... and again the same error!

 

BTW, I also accidentally opend one of the bewly created sheets in Prime 6 and recalc was OK. But just because Prime 6 has a new symbolic engine under the hood (FriCAS ionstead of muPad). When I switch back to muPad in P6, the very same error still occurs - calculations does not come to an end when trying to recalc. In the picture you still see the result of FriCAS (not as pretty as the muPad one) while Prime is trying to evaluate with muPad.

clipboard_image_0.png

 

So I am out of ideas as to what the reason for this effect could be and why the problem did not show up much earlier here in the forum - just one crude workaround I stepped over by chance:

When the calculation of a.n runs endless, stop all calculations, delete the modifier "float,3", start auto-calc. The calculation should work now. Then you can again add the "float, 3" modifier and the region still evaluated flawless.

Guess you will have to do that with every single problem region 😞

 

You may consider avoiding float mode by NOT using "float" and NOT using the decimal point (but rather use exact fractions). This seems to avoid this strange effect and will give you better results in many cases.

And if you add "assume, n=integer" as modifier, expressions like sin(n*pi) will correctly simplify to 0, etc.

Not sure if you know, that the "float" modifier does not only affect the display of the result but also the precision of the whole calculation. Thats the reason this modifier should used rather sparingly and with special care anyway.

 

I add the short test files I retped in Prime 4 and 5 in case somebody wants to give it a try, too.

 

-
-MFra-21-Topaz II
21-Topaz II
October 8, 2019

In fact, I defined the index n at the beginning of the file. The file is attached along with another one I created some time ago on the same topic (suitable for a 17 'display). Note that the piecewise linear functions can be constructed using the Heaviside step function to incorporate the intervals. P6 manages to derive but it doesn't seem to me to be able to integrate them, as can be seen in the file.

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019

Sure, Fourier series could be done better, more efficient, etc. than shown in the sheet of @Annesofieoe .

But that all does not affect the very essence of the question which is "Why do we end up in a never ending symbolic calcuation when we use "float,3" (as explained in more detail in my answer above) after saving and reloading the worksheet?".

Can you reproduce the erroneous effect, too? Any idea whats going on?

It looks like what we got was the work of a student which the teacher was no able to let recalculate. maybe also the student saved during a test and then reloaded and wasn't able to reproduce the results then. After all we see that there are some questions unanswered in the sheet and that the student assumed a period of 10 while a period of 5 was demanded. He or she assumes L is half of the period but at least in the text I read about "period L=5". In the next task the period is called p, though, so I am not sure as I don't speak Danish.

 

BTW, the original sheet @Annesofieoe posted could be opened with Prime 4, so I guess she will not be able to open your files which are created by Prime 6.

W
Werner_E25-Diamond I
25-Diamond I
October 8, 2019

The following has nothing to do with the recalc problem in discussion here.

I was just about to show a way to get the symbolic Fourier coefficients automatically for any piecewise defined function and also wanted to demonstrate the simplification of sin(k*pi) to zero if k is an integer.

This works pretty straightforward in good old Mathcad 15

clipboard_image_0.png

but when I try it in Prime 4 or Prime 5 I get a stupid error which shouldn't be there

clipboard_image_2.png

As I use Mathcad for I am not using Prime for anything serious, mainly to answer questions here and out of curiosity. So I wonder why this bug had not shown up sooner.

Does anybody know a workaround so we can talk Prime into simplifying the expression to zero.

BTW, I also tried it with Prime 6 and the new symbolic correctly simplified to 0 (even without having to use "simplify") - point for FriCAS. Even when I switched to the old symbolic I got the correct result (but had to add "simplify") and not the stupid error.

 

I attach the Fourier-sheet I was talking about nonetheless (format Prime 4). Unfortunately because of this bug the results are not fully simplified 😞

clipboard_image_3.png

 

    W
    Werner_E25-Diamond I
    25-Diamond I
    October 8, 2019

    Addendum:

    Looks like the "assume" keyword generally is broken in Prime 4 and Prime 5:

    clipboard_image_2.png

    This is what it should look like

    clipboard_image_0.png

    and the help in Prime also states that it should work

    clipboard_image_1.png

    In the help we see a correct Prime expression, so I suppose it was OK in the earlier Prime version and they broke it later, probably when they published Prime 4. Can't test it as I have no version prior to P4 installed anymore.

    Terms & ConditionsAccessibility statement