cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

Error in Mathcad programming?

ValeryOchkov
24-Ruby IV

Error in Mathcad programming?

Error or not error: that is the question!

In Mathcad MM and Mathcad Prime Minister all is OK - see http://communities.ptc.com/docs/DOC-2513

LocalVar-Return-Error.png

14 REPLIES 14

Valery,

I don't think the assignment statement (with the arrow) allows a program to be assigned, only a mathematical expression.

The following would work,

assign.JPG

There is no need to define a "subroutine" or program construct within another. They can be defined individually and then used within each other as I have shown above.

Harvey Hensley wrote:

Valery,

There is no need to define a "subroutine" or program construct within another. They can be defined individually and then used within each other as I have shown above.

Thanks, I know it,

but I want to have a program built from separate debugged modules without user functions!?

LocalVar-Return-Error-1.png

Not so much an error as a convention. The "return" operator stops the whole program, not just the module. Remove the first "return" in your examples and the results are as expected.

Alan

AlanStevens wrote:

Not so much an error as a convention. The "return" operator stops the whole program, not just the module. Remove the first "return" in your examples and the results are as expected.

Alan

Thanks, I know it.

But more correct is - http://communities.ptc.com/docs/DOC-2513

ValeryOchkov wrote:

...

But more correct is - http://communities.ptc.com/docs/DOC-2513

I don't agree! It's neither more nor less correct - it's just a convention!

Also, I don't think it's generally a good idea to include multiple modules explicitly within a Mathcad program. They are better defined as seperately programmed functions called by the main program. This is because of the clumsy notation used by Mathcad's programming structure - all those lines tend to make for a lack of clarity. For me, clarity is paramount.

Alan.

AlanStevens wrote:

ValeryOchkov wrote:

...

But more correct is - http://communities.ptc.com/docs/DOC-2513

For me, clarity is paramount.

Alan.

sorry, but for me - the correctness of calculation

I guess we'll have to agree to disagree on this one Valery!

Alan

AlanStevens wrote:

I guess we'll have to agree to disagree on this one Valery!

Alan

Sorry, what is it "we".

In old Russia only Tsar can say: "We, Nikolay II"

Or in UK - "We, Elizabeth II"

I agree with Alan. In your second example the return statement is doing exactly what it is documented to do. I absolutely would NOT want it to do what you are proposing, because if it did how would I exit the program from the nested structure if that is what I did want?

In your third example, a local assignment is local to the program, not any particular part of it, so the result is correct. If you want your proposed answer then the solution is to use a different variable name in the nested part of the program. In a large program having variables change scope depending on he level at which they are nested would lead to immense confusion.

I think it is not logically:

Returns.PNG

It is logical.

In your second structure "return" does exactly what it is documented to do. It exits the program and passes back a+3 as the output.

In your first structure your red arrow is in the wrong place. The return statement is not executed at that point in the program, because c(b) is a function definition. The return statement is only executed when the function in invoked, not when it is defined, which is on the last line of the program. The problem with this example is not a lack of logic in what it does, but a lack of documentation about what to expect (at least, I couldn't find anything). In a local function assignment statements in the function definition, including the return statement, are strictly local to that function definition. This is entirely logical, because it's exactly how function definitions behave at the worksheet level. In a nutshell, everything on the RHS of a function defintion is local to that function defintion, regardless of the scope of that defintion.

AlanStevens wrote:

Not so much an error as a convention. The "return" operator stops the whole program, not just the module. Remove the first "return" in your examples and the results are as expected.

Alan

See - http://communities.ptc.com/message/176459

MikeArmstrong
5-Regular Member
(To:ValeryOchkov)

Very strange behavior.

Mike

MikeArmstrong wrote:

Very strange behavior.

Mike

In Mathcad MM and Mathcad Prime Minister all is OK - see http://communities.ptc.com/docs/DOC-2513

Top Tags