Skip to main content
W
Werner_E25-Diamond I
25-Diamond I
April 17, 2014
Solved

return or not return? Is it a bug? Explanation needed!

  • April 17, 2014
  • 2 replies
  • 2478 views

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.

return_or_not.png

EDIT: A symbolic eval would not even simplify the result to a number (a second symbolic or numeric eval afterwards will do) - its weird!!

return_or_not2.png

EDIT2: The very same behaviour is shown in Prime 3, too

Best answer by RichardJ

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" ?

2 replies

R
RichardJ19-TanzaniteAnswer
19-Tanzanite
April 17, 2014

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" ?

    W
    Werner_E25-Diamond IAuthor
    25-Diamond I
    April 17, 2014

    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)

    R
    RichardJ19-Tanzanite
    19-Tanzanite
    April 17, 2014

    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.

    V
    ValeryOchkov24-Ruby IV
    24-Ruby IV
    April 19, 2014

    See http://communities.ptc.com/message/190849#190849 pls

    W
    Werner_E25-Diamond IAuthor
    25-Diamond I
    April 19, 2014

    Valery Ochkov wrote:

    See http://communities.ptc.com/message/190849#190849 pls

    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!

    Terms & ConditionsAccessibility statement