Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
I am new to programming in MathCad but have done plenty of while loops in other programs. I can't figure out what I am doing wrong here. Please help. I know the while loop converges because I can do it by hand in a few iterations.
Thank you for anyone who has a few minutes to take a look.
Solved! Go to Solution.
I am using Prime 3.0 and I get the division by zero error no matter if I recalc or rename t.
Its clearly a bug and I think we already had a thread about it quite some time ago.
As far as I recall Stuart and Luc are using Prime 3.1, so chances are that the bug is already fixed.
When you open a Prime file no recalculation is done but you see the result of the last calculation done before saving the file.
So when you open the file, you saw what Dustin saw in his older version of Mathcad.
Inside the while loop the global variable t.zu seems to be treated as a fresh local variable being zero:
Crazy enough, simply using/mentioning t.zu in any way before the loop cures the problem:
Turning the routine into a (dummy) function also works:
Given the answers of Stuart and Luc it really looks like its a bug present in Prime 3.0 (and below ?) which was fixed in Prime 3.1.
Werner
Dustin Saldivar wrote:
I am new to programming in MathCad but have done plenty of while loops in other programs. I can't figure out what I am doing wrong here. Please help. I know the while loop converges because I can do it by hand in a few iterations.
What problem are you having?
When I first opened it, it was showing a divide by zero error on the 45s/5 in the Ratio_t expression. However, doing a recalculate gave an answer of about 4300 seconds.
Stuart
The problem (most probably) lies with the fact that your expression for t uses t inside (the program).
If you change the occurrences of t inside the program to (e.g. ) tau, you get a result of 4.272 ks.
Success!
Luc
I am using Prime 3.0 and I get the division by zero error no matter if I recalc or rename t.
Its clearly a bug and I think we already had a thread about it quite some time ago.
As far as I recall Stuart and Luc are using Prime 3.1, so chances are that the bug is already fixed.
When you open a Prime file no recalculation is done but you see the result of the last calculation done before saving the file.
So when you open the file, you saw what Dustin saw in his older version of Mathcad.
Inside the while loop the global variable t.zu seems to be treated as a fresh local variable being zero:
Crazy enough, simply using/mentioning t.zu in any way before the loop cures the problem:
Turning the routine into a (dummy) function also works:
Given the answers of Stuart and Luc it really looks like its a bug present in Prime 3.0 (and below ?) which was fixed in Prime 3.1.
Werner
I don't know about Stuart, but my Prime is 3.1 Express (No programs...). I was able to open the file and see the error message, but upon re-evaluation I got the 'programming is a prime feature' message.
So I did my exploration in my favourite Mathcad 11, where it wouldn't work similar to what Dustin found.
Now I still think the problem is due to t being the result of the program AND being used inside that program simultaneously.
You sort of separated them by making the result of the program a function, rather than a variable. How the mentioning of t.zu resolves it I have no clue.
Luc
No, the same name for the variable, where the result is stored later and the local variable t should not be a problem. While in the program Mathad does not "see" the global t and simply returns a numeric value afte it has finnished the program. It doesn not matter what global variable this result is stored.
Jut got my hand on a machine with 3.1 and - voila - the error is gone (after recalculation).
So its pretty sure a bug which is fixed in Prime 3.1.
WE
Thank you very much. That work around did the trick. I am also glad to know that I am not crazy and that it is likely a bug.
You are welcome.
Nevertheless I feel that its better to make a program self-contained and not relying on global variables.
So I guess that I would turn the calculation into a function with all the necessary values as arguments:
EDIT: You should return t.xu, not t. That way gaining one more iteration.
Yes, that is much cleaner. Thank you. I don't have much time in MathCad and haven't tried any functions yet.