Hi Annesofieoe,
Indexing is incorrect (see photo). You should use the appropriate equality operators (see photo).
@-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:
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.
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.
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.
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.
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.
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
but when I try it in Prime 4 or Prime 5 I get a stupid error which shouldn't be there
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 😞
Addendum:
Looks like the "assume" keyword generally is broken in Prime 4 and Prime 5:
This is what it should look like
and the help in Prime also states that it should work
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.
