Mathcad Programming

[mzeftel]

We want to improve the programming features in Mathcad for the next release. Can you post or email your suggestions and wishes? For now, we're just looking at the basic programming feature, not dlls and scriptable objects.

Thanks,

Mona

[TomGutman]

>>Say MC14 (or earlier) worksheet has

Statement1 IF condition1
Statement2 IF condition2
Statement3 IF condition3
Otherwise doSomething

And we turn it into:

IF condition1
Statement1
IF condition2
Statement2
IF NOT(condition1) AND NOT(condition2)
Statement3
<<

Will work -- mostly. But far from guaranteed. The problem is that Mathcad expressions can have state and/or side effects. Duplicating an expression that involves functions with state or side effects changes the semantics of the program. A prime example would be where the condions involve a random number generator.
__________________
� � � � Tom Gutman

[RichardJ]

On 2/12/2010 8:59:04 PM, Tom Gutman wrote:

>Will work -- mostly. But far
>from guaranteed. The problem
>is that Mathcad expressions
>can have state and/or side
>effects. Duplicating an
>expression that involves
>functions with state or side
>effects changes the semantics
>of the program. A prime
>example would be where the
>condions involve a random
>number generator.

Of if the conditions just contain an assignment. I can't think of any worksheet of mine for which that is true, but it is possible to write such a condition.

Richard

[TomGutman]

>>That's a good point, but it's easily fixed by allowing an and_if statement as well as an else_if statement. A little unconventional (I am not aware of any other language that has this), but it is clear what it means.<<

Not at all clear what it means. Naively, I would expect and and_if to require that both the preceding if as well as the current condition be satisfied. Not at all the current semantics.

>>If you use that notation there is no "otherwise" allowed (someone can correct me if I am wrong about that, but I believe that is true). <<

I wouldn't take Wikipedia as authoratative on anything. It just represents, at best, one person's opinion. I'm pretty sure I've seen the use of otherwise in math texts. I believe that the only proper reference is a suitably large collection of math texts, math as actually used and printed.

>>if you don't know Mathcad very well, what does this do? Does it execute all the statements for which the condition is true, or does it drop out of the block when it finds the first one? Is it even a block, or are the if statements all independent and the "otherwise" only applies to the last one? There is no way to know just by looking at it, and that is a problem.<<

I agree that there is a bit of a problem with the usage. In normal usage for piecewise defined functions, it is considered an error if more than one condition is true (possible exception -- sometimes multiple true conditions are acceptable provided the associated values are the same, often happens at the endpoints of a continuous piecewise defined function where it makes no difference which of the two adjacent intervals the endpoint is taken to lie in). This restriction on usage for piecewise defined functions was not carried through to the generalization of the if statement. In practice, if the questions you raise are actually germain, then the function is not properly defined.

While there is certainly room for a better if construct, with clear cut boundaries, I am loathe to destroy what currently exists, both as to compatibility and matching mathematical usage for a common case. Perhaps one can leave the existing if/otherwise alone, with all its problems, and merely add elseif and else statements. A block would be started with a simple if, continued with any number of elseif statements, and, optionally, terminated with a single else statement. The boundaries are clear -- any else of elseif is related to the single preceding if, and any intervening elseif's.
__________________
� � � � Tom Gutman

[SteenGroðe]

This idea is a NO GO unless something else is going to replace the current IF stucture.
Please begin to think Mathcad as a mathematical software, instead of a programming software. I believe somebody began to forget this around version 8 and it is getting more and more worse.
BTW form my point of view it mostly just sounds as if the programmers wants to make a bader parser, but I probably miss out on something.
I have several years ago suggested to implement one liner IF (at the moment any IF has to be a two liner so one has to repeat a single IF if there is only one) and suggested more than options to write piecewise mathematical functions.
Before implementing any new IF structures, and CASEs you have to care of this, and make sure that old piecewise functions is converted automatically.


Steen Gro�e

[StuartBruff]

On 2/15/2010 2:36:51 PM, Stuart Bruff wrote:
>On 2/14/2010 8:14:38 PM, Mona Zeftel
>wrote:
>== I don't think we are going to revive
>something from Mathcad 7, and am not
>aware of others complaining about this.
>
>I hate to sound like a stuck record, but
>what "others" complain about should not
>be the driving criterion for deciding
>whether a feature needs adding or not.
>It should be decided upon its own merits
>and potential versus likely problems.
>
>I support Steen's view that Mathcad must
>be treated from a mathematical viewpoint
>first and foremost - what will the Prof
>or Lead Design Engineer scribble on his
>whiteboard and what will you find in
>their textbooks. That should inform any
>decisions. A programming viewpoint
>should only come into it where there is
>no clear alternative or the necessities
>of dealing with the flow of data push
>the decision into the programming domain
>(eg file I/O)

Forgot to add, Just because they aren't M14 doesn't mean it was worse. SUC is still there and that has certainly been complained about. Are there any plans to get rid of it in M15?

Ideally, I'd like a piecewise function implementing, as that is the more mathematical approach to dealing with alternatives. We've had several discussion about this on the Main Collab, eg http://collab.mathsoft.com/read?130046,12

Given that Mathcad uses MuPad as its symbolic engine it might be worthwhile considering emulating the MuPad function piecewise - http://www.mathworks.com/access/helpdesk/help/toolbox/mupad/index.html

Note also MuPad's 'if' and 'case' structures. On subject, I would prefer to see the keyword 'elif' used to avoid any confusion with

if condition
.. statement
else
.. if condition
.... statement
.. statement
.. statement

which is not the same as

if condition
.. statement
else if condition
statement
statement
statement

Hopefully, the indentation should give the game away, but you never can tell with humans ...

In addition, 'elif' is the keyword that both Maple and MuPad use.

Stuart

[StuartBruff]

On 2/15/2010 3:19:41 PM, Mona Zeftel wrote:
== My point to Steen was both that we are not going to return to something in a very old version of Mathcad if the vast majority of users are happy with how programming, for instance is working now.

Indeed, but the caveat is that the "old" way of doing business may be something that the majority would appreciate once they a) knew about it, b) experienced it (and got used to it). I am often amazed by the things people will put up with ... I mean, there are people who put up with me 🙂 However, sometimes, it's not the herd you've got to please.

== But more importantly, I don't understand what he wants us to implement, so I am asking him and
others when they request a feature change to be specific.

I think Steen may be referring to this thread: http://collab.mathsoft.com/read?63146,77

Stuart

[StuartBruff]

On 2/15/2010 9:11:48 PM, Mona Zeftel wrote:
>Stuart,
>
>I'm not getting to the post by
>following the link or typing
>it in. Can
>you send me the title of the
>post so I can search for it.

Sure, Mona. The Title is "One line if - trick wanted" (or search for "heart") and it was posted on 24 Nov 04.

Stuart

[RichardJ]

On 2/15/2010 2:36:51 PM, Stuart Bruff wrote:

>I support Steen's view that Mathcad must
>be treated from a mathematical viewpoint
>first and foremost - what will the Prof
>or Lead Design Engineer scribble on his
>whiteboard and what will you find in
>their textbooks. That should inform any
>decisions. A programming viewpoint
>should only come into it where there is
>no clear alternative or the necessities
>of dealing with the flow of data push
>the decision into the programming domain
>(eg file I/O)

I don't completely agree with you there.

At the worksheet level, I do agree. Whenever possible Mathcad should use standard math notation. That's why I would like to have the standard notation for a piecewise function definition. It would be trivial to extend that so that it could also be used for variable definitions, with no loss of clarity. It should also be possible to use it in programs, so that where appropriate we can use that syntax. Without some significant changes/extensions to the standard notation (see one of my other posts) it's not flexible enough for a real programming conditional structure though.

At the programming level, I do not agree with you. Programs will never look like standard math notation, because for the most part the appropriate standard math notation does not exist. If it does exist then using that notation is fine, but trying to hack some math notation until it works for programs is likely to just result in a mess. Maybe that's how we got the current conditional structure? It is obvious in the standard notation which statements are part of one block, and the structure always has the statement before the condition. What we have in the current programming on the other hand is a structure that is not delimited in any clear way, so it is not obvious which statements are part of one block, and the statement can be either before of after the condition, depending on the number of lines. That just makes programs hard to write, or even read, for new or occasional users. I would argue that if standard math notation is not suitable for use in a program, even with reasonable modifications (i.e, those that don't just result in some ambiguous and/or confusing structure such as we have now) then it would be better to switch to an alternative standard notation. Since we are specifically talking about programs, rather than statements at the worksheet level, a rather obvious standard notation would be one taken from programming.

IF all_else=equal THEN use_math_notation:=TRUE
ELSE_IF all_else<>equal AND Hell=Frozen THEN Hack__standard_notation_into_monstrosity=TRUE
ELSE_IF all_else<>equal AND Hell=Hot THEN use_programming_notation:=TRUE
ELSE New_and_occasional_users:=Confused.

Richard

[TedDiehl,PhD]

Hey All,

I do NOT agree with the recent direction of this post relative to making the
IF construct a strictly a Mathematical thing - it is a PROGRAMMING item on
the PROGRAMMING TOOLBAR!

As an engineer, I and other engineers use Mathcad because we can do a mix of
things, write equations that look Mathematical, use units, graph, plot and
PROGRAM.

We are talking about a PROGRAMMING TOOLBAR and PROGRAMMING features.
While I am pretty good with Mathematics, I must admit that I and many
engineers cannot easily read scholarly journals that write in purely
mathematical forms with sideways "U's", angle brackets <>, and curvy "R's"
that all supposedly have some common Mathematical definition.

However my experience says that most people understand IF, Else IF, Else -
these are all commonly used programming terms that I believe all engineers,
scientists, and mathematicians would understand. I further point out
(although I may be wrong) that "BREAK" and "ON ERROR" do not have
Mathematical symbols or meanings in a strict Mathematical world as far as I
know - I think they come from the Programming world.

Let us not forget that Engineers and others (Scientists, mathematicians ...)
use Mathcad for many purposes, one of which is to write programs and
algorithms in addition to "pure" mathematics to work with numbers and
concepts and to communicate ideas and solutions to problems.

I think there should be enough room in the sandbox to accommodate both the
Mathematical wishes and the programming wishes. But as Richard says, we are
talking about programs and not single statements in worksheets, so coming up
with some half-breed syntax that neither a Mathematician nor an Engineer
will be happy with (or would create confusion) is a very bad idea.

Since we are talking about programming, let the syntax lean in that
direction.

One other point, it would be helpful in Mathcad programming if it was easier
to define a block of code - by indent with a line, or a curly bracket before
and after, or some other way. This would perhaps allow better and clearer
control over what IF's are "blocked" with what other IFs and it would
hopefully allow easier selection and editing (cutting, moving, copying) of
large blocks of code within a Mathcad program.

I note I used the word "code" because we are talking about a programming
capability that allows me to do more than just write Mathematical
expressions.

Ted

Ted Diehl, Ph.D.
President

Bodie Technology, Inc.
Smart-Tools for Analyzing
Challenging DatasetsT
Developer of KornucopiaR
www.BodieTech.com
Ted.Diehl@BodieTech.com

[MichaelMcCann,P]

As an engineer, like Ted Diehl, I need to be able to create code that
is unambiguous and may well later be translated into a hardware form.
In that case, the surrounding Mathematical model of the system being
investigated provides the platform for testing the code. Another
class of problem is dealing with dynamic systems that change their
rules (topology, magnitudes based on "logic" based conditions). In
such cases the code may actually be used to create the derivative
block for a big set of ODEs where writing the individual equations in
any form may be totally out of the question because of their number.

In all these cases, I find the
'statement' IF 'condition'
format simply confusing, even if it does look more like the statement
of rules preceding a bit of mathematical theory in a text book. They
are never part of an actual calculation. I always force multiple
lines in the Mathcad programme evaluation and frequently use one of
them as a comment line to explain what is being done. So my code
always reads as in normal programming:
IF 'condition"
|do this
|do that

In coding software myself, the use of a CASE or SWITCH form is
natural and easily understood. It needs a break condition because
executing an early case in the set may modify the value being used to
control the switch itself. For example a state-machine, switched on
state in which execution of a case causes a state transition.

As I said before, if you made the Mathcad programme accept Matlab
syntax you could swallow Matlab whole! 🙂
Cheers,
Mike.

[RichardJ]

On 2/18/2010 9:19:33 AM, Michael J McCann wrote:

>As I said before, if you made
>the Mathcad programme accept
>Matlab
>syntax you could swallow
>Matlab whole! 🙂

Or even better, swallow Octave whole, because Octave is free! Another option would be to allow embedded Python programs. Python is open, and has huge libraries available, including extensive numeric libraries.

Richard

[MichaelMcCann,P]

I reference to absorbing Matlab,
Richard J said:
"Or even better, swallow Octave whole, because Octave is free!
Another option would be to allow embedded Python programs. Python is
open, and has huge libraries available, including extensive numeric libraries"

Taking the point seriously, Scilab may be a better bet. What I saw of
Octave indicated a low level of support, but it does claim to be a
Matlab Clone. There is also a graphic user interface. ScicosLab seems
to be a relevant offshoot, especially as I'm interested in simulation
software to do the Simulink task.
Cheers,
Mike.
===============

[RichardJ]

On 2/12/2010 8:55:29 PM, Tom Gutman wrote:

>Not at all clear what it
>means. Naively, I would
>expect and and_if to require
>that both the preceding if as
>well as the current condition
>be satisfied. Not at all the
>current semantics.

Yes, perhaps "and" was a bad choice. How about "also_if".

>I wouldn't take Wikipedia as
>authoratative on anything.

I didn't. I gave it as an example of the standard notation, not a definition of it.

>While there is certainly room
>for a better if construct,
>with clear cut boundaries, I
>am loathe to destroy what
>currently exists, both as to
>compatibility and matching
>mathematical usage for a
>common case. Perhaps one can
>leave the existing
>if/otherwise alone, with all
>its problems, and merely add
>elseif and else statements. A
>block would be started with a
>simple if, continued with any
>number of elseif statements,
>and, optionally, terminated
>with a single else statement.
>The boundaries are clear --
>any else of elseif is related
>to the single preceding if,
>and any intervening elseif's.

Here's a proposal that maybe would satisfy everyone (he says hopefully!):

Implement the standard math notation, with the left hand curly bracket. Such an if statement could be used either at the worksheet level or in a program. If used with simple one line statements for a piecewise function definition we have what many of us want: standard math notation when possible

Relax the standard rules/extend the rules for standard math notation (whatever those might be), in both the conditions and statements. So conditions or statements can be multiline, not all conditions must be accounted for, and more than one condition can be true.

Allow an "otherwise" statement", and add an "elseif" statement. Also allow other statements to be part of the conditional statement block (this is necessary for comments).

The extent of the left curly brace determines whether the statements are part of the same block, so there will no longer be any confusion over this. If I write

statement1 if condition1
statement2 if condition2
statement3 if condition3
statement4 otherwise

It will behave exactly as it does now. If I write

statement1 if condition1
"this is a comment"
statement2 if condition2
"this is another comment"
statement3 if condition3
statement4 otherwise

All the conditional statements are still part of the same block (unlike now) as long as they are contained within one left curly bracket. All the conditions are evaluated, just as they would be now.

This would allow for standard math notation, all current programs could be converted, and, unlike now, the extent of the block would be unambiguous.

Richard

[RichardJ]

On 2/15/2010 9:41:24 AM, Richard Jackson wrote:

>Relax the standard rules/extend the
>rules for standard math notation
>(whatever those might be), in both the
>conditions and statements.

I forgot one rather important rule that needs to be relaxed: there should be no requirement that there is an assignment to the left of the curly bracket.

Richard

[PhilipOakley]

Just catching up on this.

Richard's suggestion has something in it, and
addresses many of Tom's concerns in that old programmes can be automatically converted to show
how Mathcad has already 'bracketed' together the
various parts.

For myself, I would rather have Richard's 'curly
brackets' actually show as a grouping line,
specific to if/case structures. Thus the various
examples would have an extra (vertical) line,
relative to the old layout, that showed where
composite IFs where joined together.

Again this would quickly show the user where a
stray "" line broke up a group (assuming automatic
conversion of existing code).

Thus only "if" and "otherwise" could be added on
the end of a "Grouped If" line, all other
statements go into the If's 'then' location.

As an aside, the shifting of position of the
'then' portion can be confusing

On 2/15/2010 9:41:24 AM, Richard Jackson wrote:

>Here's a proposal that maybe would
>satisfy everyone (he says hopefully!):
>
>Implement the standard math notation,
>with the left hand curly bracket. Such
>an if statement could be used either at
>the worksheet level or in a program. If
>used with simple one line statements for
>a piecewise function definition we have
>what many of us want: standard math
>notation when possible
>
>Relax the standard rules/extend the
>rules for standard math notation
>(whatever those might be), in both the
>conditions and statements. So conditions
>or statements can be multiline, not all
>conditions must be accounted for, and
>more than one condition can be true.
>
>Allow an "otherwise" statement", and add
>an "elseif" statement. Also allow other
>statements to be part of the conditional
>statement block (this is necessary for
>comments).
>
>The extent of the left curly brace
>determines whether the statements are
>part of the same block, so there will no
>longer be any confusion over this. If I
>write
>
>statement1 if condition1
>statement2 if condition2
>statement3 if condition3
>statement4 otherwise
>
>It will behave exactly as it does now.
>If I write
>
>statement1 if condition1
>"this is a comment"
>statement2 if condition2
>"this is another comment"
>statement3 if condition3
>statement4 otherwise
>
>All the conditional statements are still
>part of the same block (unlike now) as
>long as they are contained within one
>left curly bracket. All the conditions
>are evaluated, just as they would be
>now.
>
>This would allow for standard math
>notation, all current programs could be
>converted, and, unlike now, the extent
>of the block would be unambiguous.
>
>Richard
>
>

Philip Oakley

[RichardJ]

On 2/17/2010 7:11:01 PM, Philip Oakley wrote:

>For myself, I would rather
>have Richard's 'curly
>brackets' actually show as a
>grouping line,
>specific to if/case
>structures.

That was my intent 🙂

>Thus the various
>examples would have an extra
>(vertical) line,
>relative to the old layout,
>that showed where
>composite IFs where joined
>together.

This is really needed. Whatever the final solution is it needs to be clear where a conditional block begins and ends. An additional vertical line would be a solution that is completely consistent with the current program structure.

Richard

[RichardJ]

On 2/12/2010 8:55:29 PM, Tom Gutman wrote:

>>>If you use that notation there is no "otherwise" allowed (someone can correct me if I am wrong about that, but I believe that is true). <<
>
>I wouldn't take Wikipedia as
>authoratative on anything. It
>just represents, at best, one
>person's opinion. I'm pretty
>sure I've seen the use of
>otherwise in math texts. I
>believe that the only proper
>reference is a suitably large
>collection of math texts, math
>as actually used and printed.

Actually, one example at the Wolfram site shows the use of "otherwise" 🙂

Richard

[StuartBruff]

On 2/12/2010 9:16:11 AM, Richard Jackson wrote:
== I think you are only half right here. First, what we have now is also not standard math notation. For those that don't know what standard notation looks like, it can be seen here
== http://en.wikipedia.org/wiki/Piecewise
== and here
== http://mathworld.wolfram.com/PiecewiseFunction.html

== If you use that notation there is no "otherwise" allowed (someone can correct me if I am wrong about that, but I believe that is true). Further, the conditions must be exclusive (so it is never possible for two conditions to be met), and all conditions must be accounted for. If either of these things is not true then the definition is not valid.

Mathematica's implementation of the piecewise function is based upon the assumption that no more than one condition will be true. See http://reference.wolfram.com/mathematica/ref/Piecewise.html

In terms of 'otherwise', most of the mathematics textbooks that I have glanced through assume that the all the conditions are explicit. However, the (overwhelming) majority of examples I have found so far where it is not explicit uses otherwise not else. As you point out in a later message, the Mathematica Piecewise function page contains an example of using 'otherwise'; the reference is actually to Knuth's Tex recommendation for layout of piecewise functions ... however, Knuth goes on to confuse matters by using 'elsewhere' in place of 'otherwise'. Mathematica itself uses 'True', as any other condition will already have been actioned and the function terminated at that point.

An interesting read is http://www.cs.utk.edu/~eijkhout/594-LaTeX/handouts/TeX%20LaTeX%20course.pdf

Section 3.4 and 5.1.4.2 give examples of 'otherwise'. The document itself discusses how to break text over lines/paragraphs/pages

Stuart

[SteenGroðe]

I understand but the distance between the two are not that far. I believe what would be nice to have is some drag and drop feature so you can pick something from a palette and drop it onto the programming line. But you should try to play a little with Scratch so you get a feeling of what I mean. Features like disconnection programs, inserting stuff and things like that are really neat.


On 12/16/2009 4:29:56 PM, Mona Zeftel wrote:
>We want to stick closely to
>our current programming
>paradigm because =users know
>it, and Mathcad programming is
>tied so closely to mathematics
>=and functions.
>
>Mona
>
>
>-----Original Message-----
>From: poweruser Listmanager
>[mailto:listmanager@collab.mat
>hsoft.com]
>Sent: Wednesday, December 16,
>2009 3:52 PM
>Subject: Mathcad Programming
>
>From: "Steen Grode"
>
>Did I mention that the
>userinterface in Scratch
>http://scratch.mit.edu/ =works
>like a charm? Programming is
>done by putting virtual
>dynamic =bricks together.
>
>Steen Gro�e
>
>
>To reply:
>mailto:poweruser.131626@collab
>.mathsoft.com
>To start a new topic:
>mailto:poweruser@collab.mathso
>ft.com
>To login:
>http://collab.mathsoft.com:80/
>~listserv/



Steen Gro�e