Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X
8. I strongly disagree with the ... conversion. Call me old-fashioned (I am after all, a skilled software engineer of 4 decades), but I will be dragged kicking and screaming to use "also if"!!! This is a very poor translation. The error message is "An instance of 'otherwise' was converted to an equivalent 'if' expression."
I don't agree with soome of the new directions of program enviroments such as MATLAB, IDL, MP3, &c. that encourage habits that I think obscure what is really happening in the code. "also if" Please! Who thought this up?
~R~
Rich Messeder wrote:
8. I strongly disagree with the ... conversion. Call me old-fashioned (I am after all, a skilled software engineer of 4 decades), but I will be dragged kicking and screaming to use "also if"!!! This is a very poor translation. The error message is "An instance of 'otherwise' was converted to an equivalent 'if' expression."
~R~
I fully agree. But I think it's one of those things we are going to have to get use to.
Mike
"also if" Please! Who thought this up?
There were good reasons to change the programming structure. A consequence of those changes was the "also if". See this thread: http://communities.ptc.com/message/197571#197571
In my opinion the changes were necessary, and I do not see an alternative to implementing "also if". If you don't like it you do not have to use it in new worksheets, but it is needed to convert MC15 worksheets.
Hmm... as you know I am one of those that really suggested a different design or maybe more different design for programming. Already around version 8 we got more or more the datalogical perspective into Mathcad which could be fine if it wasn't for the diminishing mathematics.
In theory, we could have both better programming structures and more standard mathematical notation. Theory does not always turn into practice though
I added a comment to that thread, which I didn't have time to address at the time...and you may be correct that "also if" is necessary to convert M15 docs, but then I must correct MP's conversion. My real example follows the logic of the 2nd example in that other thread. I didn't intend an "also if", M15 didn't interpret it as "also if", and I see no reason for converting it as "also if". It may well be that my programming style and conventions don't match the majority of Mathcad users, and those users need "also if". I think that "also if" and "else if" are sloppy conventions and encourage sloppy programming. I also think that multiple exit points from a routine are sloppy, but I am perhaps out of fashion there, too. In fact, I have a sort of nagging feeling that the "single entry and exit" may have derived from the prolific use of GOTO and all the horror that I have seen that create. So...while I can see the possibility of multiple returns actually cleaning up code, most of the programs where I have seen them used /also/ were very poor examples of good programming. The goal is that program flow should be as clear as possible, so I don't want to adhere to a style for the style's sake if it sacrifices clarity. OTOH, the programming in the other thread http://communities.ptc.com/message/197571#197571 is not a clear one to me, so I simply applied my best guess as to the intent and threw together some examples The OP says what is WRONG but not what is EXPECTED. I don't think that the "also if" that I got after conversion is either clearer to me or yields results that I might expect from reading the code. I looked up "also if" and "programming" in MP Help, and got nothing...dunno what keywords to use.
Prime conversion doesn't separate regions.
Try please input "-", copy it and paste it. You will get not "-" (a string -) but an operator minus.
Is it a bug?