Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X
Can anybody explain why we get different result for the boolean comparison dependent on whether we use the return statement or not?
IMHO the second expression using the return (which I consider good style) is yielding a wrong result.
EDIT: A symbolic eval would not even simplify the result to a number (a second symbolic or numeric eval afterwards will do) - its weird!!
EDIT2: The very same behaviour is shown in Prime 3, too
Solved! Go to Solution.
Mathcad sees the entire expression, including the boolean comparison, as "the program". So in the second case the return causes the program to exit before the boolean comparison occurs, and the returned value is a+b, because that's what is fed to the return statement.
Why not just make the last line "return (a+b)=3" ?
Mathcad sees the entire expression, including the boolean comparison, as "the program". So in the second case the return causes the program to exit before the boolean comparison occurs, and the returned value is a+b, because that's what is fed to the return statement.
Why not just make the last line "return (a+b)=3" ?
Mathcad sees the entire expression, including the boolean comparison, as "the program". So in the second case the return causes the program to exit before the boolean comparison occurs, and the returned value is a+b, because that's what is fed to the return statement.
Thats a sound explanantion and I guess thats exactly what happens. Nevertheless I think that Mathcad shouldn't see the boolean comparison as part of the program, especially given the way the patentheses are placed.
Why not just make the last line "return (a+b)=3" ?
Sure, that would certainly solve the problem.
You probably have already noticed that a stumbled upon this effect at ansering to this question http://communities.ptc.com/message/240454#240454
I still feel its kind of a bug (one we have enough workarounds for so that it's not really a problem, though)
I agree it does not look right, but I think it occurs because the extent of the program can only be "delimited" (for want of a better word) by either an assignment or an evaluation. Everything to the right of an assignment, or to the left of an evaluation, is part of the program.
Isee, there is logic in what you say.
Maybe it shouldn't be called a bug but just a nonintuitive implementation.
A very long time ago (back in the Mathsoft days) we tried to catalog all these "illogicalities" so that they could be fixed.
Back in the days when we dreamed of having MDAs and such in our lifetimes. Sigh.
Back in the days when we dreamed of having MDAs and such in our lifetimes. Sigh.
MDA? OK, I think you were not dreaming of having a MonochromeDisplayAdapter, weren't you? And for MassDrugAdministration Mathcad would not have enough addictive potential - OK, at least not for the masses.
MobileDigitalAssistant? - not that impossible but my best guess are MultiDimensionalArrays, right?
Those were the good old days when we thought we could get more than we had. Today we would already be happy if we could at least keep what we have so far - who would have thought that it will come to that end!? 😞
Valery Ochkov wrote:
Why? There is not the slightest correlation to the effect discussed here.
In your baublery one time you use return as the correct end of an inner, local function definition and the second time you use return in a local variable assignment (disguise as a function) which naturally ends the ("outer") function. Thats all as it should be.
And while it also uses the return statement, the effect discussed here is completely different!