Simple program - wrong return value

[Werner_E]

This is a problem I stumbled upon writing a more complex routine (http://communities.ptc.com/message/197514#197514) and was able to cut down to the attached simple programs.

Can anybody explain whats wrong with Test2()?

Why is the else branch ("otherwise") not evaluated when the first "if" is triggered??

Inserting that dummy line as in Test1() "solves" that problem, but whats the reason for this?

[Werner_E]

Converting the worksheet in Prime2 format shed a little light on the phenomenon but I'm still lacking full understanding. Changing that "also if" to a simple "if" does what I want, but how can I achieve this in Mathcad15 without inserting that dummy line?

Is still don't fully understand when and how the else branch is evaluated in that example.

[Ninetrees]

I opine that the real problem is poorly constructed programs, though I may have missed the point of this bit of logic. The program can be rewritten to reflect programming standards

So, while the "also if" may be necessary to accomodate a certain programming style, /I/ don't want what MP3 recently did to my program.

In the following, M15 does exactly what I expect, and even though I am not a fan of the current M1x or MP programming metaphor, both are OK for what they do: M1x is not complete enough and requires those extra "" lines to clean up the logic, and MP's || lines are superfluous when single lines suffice (and I prefer them).

[Werner_E]

After some more investigation (RTFM, aka Mathcad help) it seems that this behaviour is implemented on purpose and I guess the only way to deal with it is to add an extra line - either the dummy I had inserted or a dummy "otherwise" statement after the first if.

From the MC15 help:

• If you use more than one if statement before an otherwise statement, the otherwise statement is executed only when all previous conditions are false. However, all previous if statements continue to be evaluated regardless of the results of the previous if. In the example above fy(5) = 9 and fy(2) = 1. There is no "else if" or "case" statement in Mathcad that allows you to switch on multiple cases, other than to use nested if ... otherwise pairs.

As Mona wrote in a thread last year (http://communities.ptc.com/message/183475#183475) the "also if" was introduced in Prime2 for backwards compatibility. In Prime a sequence of if-statements before an otherwise-statement evaluates the way I expected it to do in MC15.

Should I change my opinion regarding Prime? No. Should I remind myself that Mathcad15's help is feasible, quite complete and worth a look? Yes!

I only wonder why I didn't came across that descrepancy sooner, or did I?

[RichardJ · Accepted solution]

I only wonder why I didn't came across that descrepancy sooner, or did I?

You got lucky?

In MC15 the only ways to terminate a conditional block is with either an "otherwise", or a line with no conditional statement in it. Since the only conditional statements available are "if" and "otherwise", there had to be a choice between evaluating all consecutive if statements, or exiting the block when any one was true. I guess it was decided the lesser of two evils was to evaluate all of them (a decision I personally agree with). Since the "otherwise" is only meant as a trap when none of the conditions are met, in my opinion it is logical that it is not evaluated unless none of the conditions are met. So your test1 program has two conditional blocks, but your test2 program has only one. It's made even more confusing by the fact that you don't have a return statement on the first line. It means that in test1 the line actually has no effect at all.

You are not the first person to be confused by this behavior (surprise!). Even if you know how it works, it can also make it hard to figure out what a program will actually do. It's also rather limiting, because sometimes what you want is an "else if" or case statement, but that is not easy to create in MC15. Hence the changes in Prime. There are things I don't like about Prime, but IMHO the new conditional structure is a huge improvement.

[Werner_E]

I only wonder why I didn't came across that descrepancy sooner, or did I?

You got lucky?

Seems so.

In MC15 the only ways to terminate a conditional block is with either an "otherwise", or a line with no conditional statement in it. Since the only conditional statements available are "if" and "otherwise", there had to be a choice between evaluating all consecutive if statements, or exiting the block when any one was true. I guess it was decided the lesser of two evils was to evaluate all of them (a decision I personally agree with).

So there is no other solution as adding that extra line - not necessary to search for another workaround.

I was assuming that mathcad would behave like any other programming language which only offer if and else: if an if-statement is not followed by an else it is finished. If you want a cascading evaluation you would have to put the second if in the else (otherwise) branch. MC 15 behaves differently - good to know (hope i will remember).

It's made even more confusing by the fact that you don't have a return statement on the first line. It means that in test1 the line actually has no effect at all.

You are talking of the "XXX" line. In the "real" program I was workin on there is some kind of evaluation there, a loop if i remember correct. I tried to track down the problem and simplified it as much as possible which helped me to find out what was going on. So i found that the first if (which had nothing to do with the last one) was responsible for the troubles.

There are things I don't like about Prime, but IMHO the new conditional structure is a huge improvement.

I tend to agree. The new modifiers of the lookup functions are an improvement, too. Its not all bad in Prime, but...

Thanks for your explanations!

[StuartBruff]

Richard Jackson wrote:

I only wonder why I didn't came across that descrepancy sooner, or did I?

You got lucky?

I'll second that. I vaguely recall the first time I hit the problem. Of course, I didn't remember it well enough to avoid hitting it again!

Richard Jackson wrote:

There are things I don't like about Prime, but IMHO the new conditional structure is a huge improvement.

Yeeess, it is an improvement structurally but I have to confess to preferring the more compact one line structure (that I know others don't) and "otherwise" as opposed to "else" ... I think there's a little to much "programmer" mentality about Prime and not enough "mathematician" or "engineer".

I would have preferred (at least as an option) to have the ability to express conditional equations in "standard" maths piecewise format rather than a program. Eg,

I wrote a worksheet that contained a 'piecewise' function that attempted to emulate this pattern ... worked better in M11 due to lack of SUC. However, I can't find it, so the attached will have to do.

Stuart

[Werner_E]

Thanks for those examples.

I'm still stuck at the first part thinking what logic I am missing as of the difference between the two definitions of f(x), one without, the other with return and why the evaluation of the if sequence is different because of this. After reading the help and Richards explanations I thought I understand the way MC15 deals with if-sequences - a mistake 😞

[StuartBruff]

Werner Exinger wrote:

Thanks for those examples.

I'm still stuck at the first part thinking what logic I am missing as of the difference between the two definitions of f(x), one without, the other with return and why the evaluation of the if sequence is different because of this. After reading the help and Richards explanations I thought I understand the way MC15 deals with if-sequences - a mistake 😞

Assuming that I've interpreted you correctly, the evaluation has nothing to do with the lack of a return statement in the first line (ie, x>1). It is purely to do with the if-otherwise statements being contiguous.

Starting at the beginning, Mathcad evaluates x>1 and if it is true, it then evaluates the string "XXXX", which becomes the last value calculated by Mathcad.

In version 1, Mathcad then encounters your comment "If I delete ..." and evaluates this which replaces "XXXX" as the last calcuated value.

In version 2, Mathcad notes that it has moved straight on to another if statement, but keeps track of the fact that it either has, or has not, determined x>1 to be true. If it was true, then Matchad retains "XXXX" as the last calculated value.

If y=0 then "AAAA" replaces "XXXX", Mathcad skips the otherwise clause and returns the newly calculated "AAAA".

If y is not equal to 0, however, Mathcad check whether the first condition (x > 1) was true and if so, again skips the otherwise clause to return its last calculated value of "XXXX".

To see what's happening a little bit more clearly, copy your Test1 and delete the otherwise clause at the end ... hopefully, you should see your comment appear.

Stuart

[Werner_E]

Sorry 'bout my bad english.

What I was talking about was not my functions, I think (thought?) that I understand how those contiguous if-statements work in MC15 and why that extra line changes the behaviour..

I was talking about the two f(x) in the sheet _you_ had posted. They behave differently only becuase you added explicitely the return statements.

Or is it because no program lines are executed after a return-statement?

Edited: OK I just gave it a try. Its as a wrote above. A program terminates when it comes to evaluate a return statement. Thats the reason for the difference in your two f(x) routines.

Think the knot in my brain has untied now.

[RichardJ]

A program terminates when it comes to evaluate a return statement.

Yes, exactly. The program exits, returning the value of the expression that is the argument to the return statement. That's what I was alluding to when I said that the first line of your program not having a return statement makes it even more confusing. If it did, then if x>1 the program would return "XXX", and the second if statement would never even be evaluated.

[RichardJ]

Yeeess, it is an improvement structurally but I have to confess to preferring the more compact one line structure

Yes, I would like this as an option.

I have to confess to preferring the more compact one line structure (that I know others don't) and "otherwise" as opposed to "else" ... I think there's a little to much "programmer" mentality about Prime and not enough "mathematician" or "engineer".

Within programs, I don't have a problem with it. I don't believe you can ever make programs look like anything other than programs (at least, not if you want to retain any real flexibility), so switching to programmer mentality is fine with me. In then end it's less confusing to most people. Anyway, any mathematician or engineer that doesn't know what "else if" means in a program, and even if they don't know can't figure it out, should be thrown into the boiling hell of a liberal arts collage until they have redeemed themselves

I would have preferred (at least as an option) to have the ability to express conditional equations in "standard" maths piecewise format rather than a program. Eg,

At the worksheet level, I agree 100%. I think we have discussed this in the past

[StuartBruff]

Richard Jackson wrote:

Within programs, I don't have a problem with it. I don't believe you can ever make programs look like anything other than programs (at least, not if you want to retain any real flexibility), so switching to programmer mentality is fine with me. In then end it's less confusing to most people.

It depends how you define program. I've also suggested options (eg, subworksheets) for creating program together with worksheet looping mechanisms. Many people seem happy with laying out a worksheet on a region-by-region basis, at least if the number of times we end up suggesting that such implementations be wrapped up into a function is anything to go by!

Anyway, any mathematician or engineer that doesn't know what "else if" means in a program, and even if they don't know can't figure it out, should be thrown into the boiling hell of a liberal arts collage until they have redeemed themselves

I think I suggested that option when Mathsoft mucked around with static typing and crippling recursion ... didn't happen.

I would have preferred (at least as an option) to have the ability to express conditional equations in "standard" maths piecewise format rather than a program. Eg,

At the worksheet level, I agree 100%. I think we have discussed this in the past

Yes, we have, IIRC. I'd be happy to use it in a program as well.

Stuart