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

[MichaelMcCann,P]

Mona,
I use programming fairly extensively on some jobs and I find the
basic ideas fine, the range of coding options is Ok and the ability
to use Mathcad constructs inside programmes makes it more powerful
than it looks. However, I do have some things I'd like to see
changed. Note that I'm not a computer science person, but an engineer user.

The use of "if":
The programme construct is different from the MC if(,,) function but
that isn't what irritates me; it's about layout. The "if(,,) function
can indeed be used inside a programme block.
For a single line of code the conditional action is on the left of
the "if" but as soon as I want to make two or more lines of code in
the conditional 'then' part it jumps to being under the 'if'
line. I'm sure it was based on the idea that the action was expected
to be a numeric value to be assigned by default to the output
variable (similar to the MC function) but it makes a mess of the
layout and makes confusing reading as all the programming languages I
know follow the rule of having conditional actions after the 'if'.
Indeed, when writing MC code I deliberately insert a dummy line for
the conditional action so as to maintain readability. A bit of text
does the trick but editing it is risky.
Along with this is the confusion of nested "if's". If I'm not
careful, I get the code block expanding out to the right with the
relationships unreadable (as I see it). So I have to make the tested
conditions mutually exclusive so that I can write a programme that
reads downwards. In a way I'm creating a "CASE" or "SWITCH" block.
The answer is perhaps to make such a construct available.

Otherwise.
after filling in the blanks in a basic '[] if []' template it seems
natural to insert 'otherwise' if it's needed. BUT beware: you have to
insert a new line first. It won't do it for you and the result is
automatically a failure and uneditable. So you have to go back and restart.

Editing in General:
I find it perpetually irritating that backspace key only undoes the
previous keystroke sometimes and I don't know when. In programming
it's at its worst.
Some structures can't be entered to make changes and I often have to
create a chunk of an expression separately and put it in place of a
[] rather than risk losing control of the editing process.

Looping "for"
The specification as a range like the rest of MC is fine. But is it
necessary always to have to use "for". Matlab and MC both have
implicit indexing. In MC defining a range variable then using it as
an index on the LHS of an assignment causes iteration. Matlab has the
colon operator that is even more powerful, making it do something
like "for all cases" regardless of size of vector or matrix. Can we
use the MC form inside a programme block?

Debugging.
1. I often use the programme block as the means to do an iterative
calculation. The output variable may be a matrix, vector or data
structure with different parts but all indexed by some range variable
defined before starting. A simple example is the iterative numerical
solution of a difference equation. The LHS indexed as (n+1) is
defined by a programme block that uses LHS indexed by n. The LHS
index 0 is the initial condition.
The problem I find is that my calculation may proceed Ok for a while
but then an error occurs well into the evaluation. So it stops and
complains but I don't get any output of has been done so far so I can
see how the problem developed. I'd like to be able to look at the
results so far, even if the range iteration has not been completed.
2. The tracing of coding errors is often quite hopeless. The system
may point to an error but the real error can be quite different.
Examples seem to occur when a variable inside the code is actually
the same as a name outside though having this as a way to
parameterize and provide exogenous variables is a big improvement
over the ODE solvers' inability to use parameterized derivative functions.

Layout:
If my LHS is a function definition with along list of parameters,
any significant programme is going to get pushed off the page on the
RHS (even in landscape mode!). Can we have an option to have the "LHS
(,,,,,):= " placed above the programme? I know we could use some
complex data structure but the clients get confused (and so do I when
I come back to it).

Functions Inside loops inside Programmes.
I can use this to parameterize differential equations so as to run
through a sequence of them. I haven't had occasion to try linking the
successive solutions (eg solving a hyperbolic PDE) in a programme.
What I didn't find was any suitable "Help" reference to this ability
to re-define functions inside the programme.

I have attached a file for you with these programming points illustrated.


Hope this helps,
Cheers,
Mike.
=======================

[PhilipOakley]

The "On Error" has always bugged me as to which argument is to be evaluated first. Just like Mike McCann's comment about 'if' swapping around its locations, the "On error" is horrible.

I also support Mike's debugging (1) comment about remebering the result 'so far' in some way, so that a 'trace' can be done of the current temporary results, rather than having to second guess which trace statement to insert and then re-run...

Finally, a way of grouping a large section (e.g. an Area) of region calcs and making them into a putative programme, such that one can insert variable values at the start of that sequence and see the alternative results. (Stuart Bruff, I think, has suggested that we shouldn't need to distinguish := and <- anyway)

Finally, Finally, rework the in0-in9 and API interface in line with the above para, so that we can have a worksheet that will fully execute and give results and can also be driven by the API to set some of the variable value at a point not at the immediate start of the programme (e.g. at the start line of a named area, or just prior to region number/tag). And be able to retieve a variable's value at a particular point (again just after an Area, region number or Region tag)
[I like this one as it creates a nice consistent level of abstraction that works well with the improvement and separtion of the core compute engine from the GUI with an implied interaction-API]

Philip Oakley

[MichaelMcCann,P]

Mona, Philip and all,
SYNTAX:
Philip's comment about not distinguishing <- from := is a good
point. I could use that to develop a solution method then pack it in
a programme to be parameterized or driven by external data. By the
same thinking, the definition of a range variable could be the same
as in the rest of Mathcad (eg n:=1..10). That leads to the request,
whose satisfaction may be implicit in the change, to allow us to
type in ':' (for ':=' ) and the keywords 'if', 'while', 'otherwise'
or even maybe 'then' and 'else'.
I've already suggested we have implicit looping (indexed variables
on LHS of statements) so that 'for' will not be needed so
much. Matlab exploits this to make it's interpreted operation much
faster and Mathcad does it in the body of the document. That would
also allow carry over into making programmes from normal document statements.

LAYOUT:
I'd also like to suggest, in terms of layout:

1. that we be allowed to put several statements on one line,
separated by a semi-colon and some spaces. Often I have a programme
that is long vertically, simply because there are lots of little
statements and since the individual statements are Mathcad they can
be very powerful.

2. we be allowed to have comments at the ends of lines (which on a
empty line is the whole line). While Mathsoft/PTC might not like to
admit it, some compatibility with Matlab is not a bad thing, so the
symbol should be %. At present I have to put comments alongside the
programme which gets mucked up if the programme is modified as the
alignment gets shot. (Dummy lines that contain only a "string" are
admittedly a partial substitute.)

3. the default layout editing behaviour be to move text down and
apply this to programmes as well. Every time I add something to a
programme it messes up the following analysis.

As I see it, these changes would not cripple any existing Mathcad documents.

DEBUGGING
As another aspect of my work, I'm currently having to learn MATLAB to
keep up with some students in the University of Bristol (UK).
Matlab's output document is poor at best, but there is a feature of
m-files, which are comparable to Mathcad programmes, that could be
very helpful particularly in debugging:

1. Cell Rules: A marked cell (portion of the programme/script) is run
on its own and results can be delivered to the command window or
figures (graphs) in passing). We could do that in Mathcad, using the
aforementioned comment lines which, with %% at the start, would
break the programme into cells. (It's a big aid to finding which bits
are OK or not).
Because the Mathcad programme is considered to be placed/computed at
the location of its top line, then we can display intermediate
results alongside the programme. Of course the debugging/trace window
is an option but it takes valuable vertical screen space. It will
need some means of suppressing the behaviour (especially for
variables in loops) when the whole programme is run, but that could
be linked to switching cell rules on and off or with the options for
debugging.
With this, we have a means of running a programme AND showing
running/intermediate output as calculations proceed. I can imagine
having a programme option to flag a variable to be displayable
(during debugging or single shot runs) so that it can be monitored
and as a bonus, provide extra output variables that don't have to be
built in to the output data structure (now limited to one nominal
variable). A possible method is to allow the programme to create
named strings that are displayed alongside the code, but making the
local/running output have any form (string, vector, structure) would
be less restrictive. My preferred suggestion is consistent with the
change in syntax rules as above: Allow the use of the evaluative '='
symbol in a programme so it automatically comes out wherever the same
variable name is similarly used in the document, below the top line
of the programme. As far as I can see that wouldn't break any 'scope
of variables' rules.
With luck we will have less occasion to wonder, while "Trace
error" is totally confused, what went wrong.

2. Graphs on the fly: If we extend the idea of delivering a variable
to the outside (of the programme) while it runs then there should be
no problem with displaying it in graphical form as well.

OTHER LANGUAGES:
SciLab and Octave provide a good deal of Matlab compatibility.
Wouldn't it be neat if we could pick up a bit of Matlab or other code
that someone has given us and drop it into a Mathcad programme? I can
imagine dropping the contents of an m-file function or script into
Mathcad, perhaps editing it to pick function names and letting it
run. The idea of having Mathcad swallow Matlab whole is quite appealing!
Cheers,
Mike.
=====================

[PhilipOakley]

On 11/5/2009 8:50:39 AM, Michael J McCann wrote:
> The idea of having
>Mathcad swallow Matlab whole
>is quite appealing!
>Cheers,
>Mike.
>=====================

Yep. Mathcad swallow Matlab whole! Workflow....

I also noted Mike's "%%" 'grouping' (Matlab programme cell) idea. That looks usefull.

Implicitly, during MathCAD parsing, it already knows the variable input parameters and default parameters of groups of code, so it is possible that such cell groups are already a hidden capability.

Philip Oakley

[PhilipOakley]

On 11/2/2009 4:46:57 PM, Mona Zeftel wrote:
>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

1.) I would like a vector based indexing (to complement the range variable based indexing) This effectively would eliminate the need for a temporary range variable to index along the vector, whose values are then used as the proper index. This is to make the coding as (apparently) simple as matlab's.


2.) I'd to be able to handle variable number of arguments (both in and out). This is so that default values can be used for values if not specified, and so that useful additional information can be returned.
e.g. max(X) could return both the maximum value and its index as the useful spare value.
e.g. match(a,X,TOL) could be passed a deliberate tolerance value or use the system default

3.) I'd like the code to go a bit faster for deep repeating nested code. e.g. home coded FFT and its alternatives.

Philip Oakley

[mthackst]

For what it's worth, I like the current indentation scheme. It allows one to see what block of statements is controlled by an 'if', 'for', or 'while' very easily. There are other programming environments that use indentation as well. [As for the black lines, I don't care one way or the other.]

I also like the "local replace" being distinct from the := assignment. Actually, it might be useful to also have an assignment capability inside the program that would carry to outside the program; so, maybe both the back-arrow and the colon-equal could be allowed so that the programmer can decide which will be better for a given application.

Something that I have not seen mentioned in any note, but that I think would be a nice enhancement is this. Back some time ago (Mathcad 11 for example) there was an undocumented feature in Mathcad that is gone now. I could type "eqn:=a*x+b=7" for example, and then type "solve(eqn,x)-->" and the solution would be produced. This also worked for collect, simplify, factor, and some other words.

If we could have that back (this time, officially) and be able to incorporate a stream of these into a program, that would really be nice.


Michael Thackston
physics, SPSU

[PhilipOakley]

On 12/14/2009 11:04:47 AM, Michael Thackston wrote:
>
>Something that I have not seen
>mentioned in any note, but
>that I think would be a nice
>enhancement is this. Back
>some time ago (Mathcad 11 for
>example) there was an
>undocumented feature in
>Mathcad that is gone now. I
>could type "eqn:=a*x+b=7" for
>example, and then type
>"solve(eqn,x)-->" and the
>solution would be produced.
>This also worked for collect,
>simplify, factor, and some
>other words.
>
>If we could have that back
>(this time, officially) and be
>able to incorporate a stream
>of these into a program, that
>would really be nice.
>
>
>Michael Thackston
>physics, SPSU

I believe that it is still there. It should be better documented.

There is a thread on the main collab on that very issue yesterday.

Philip Oakley C.Eng
philipoakley@iee.org

[pbaxter-disable]

I'd really like the ability to generate multiple outputs that have different units. A simple example would be to calculate both a moment (force * distance) and shear (force) from the same program. Currently I have to make outputs unitless, then re-assign them later in the sheet.

[PhilipOakley]

One thing I find irksome is deciding which end of
"On Error" the calculation goes, and which end has
the backup.

Can you think up a few alternatives to offer? This
could be a new "text here" rather than "On error" or
a different way of representing (on the white board)
the feature. [perhaps even like "otherwise"]



I would also like a method of deciding what to do on
the two boundaries of a 2d matrix indexing. At the
moment there is no mechanism for detecting /
selecting between say [divide zero / row oob / col
oob] (oob = out of bounds), just the catch all 'any
error'

Philip Oakley

[SteenGroðe]

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

[PhilipOakley]

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
>
See Fred's comments on the main collab http://collab.mathsoft.com/read?131646,12e#131646 (#23 + #24) about MatLab winning the battle for hearts and minds...

Philip Oakley C.Eng
philipoakley@iee.org

[mzeftel]

We are considering implementing a setup like:

if condition1 then
statement1
else if condition2 then
statement2
else
statement3

rather than the Mathcad 14 version of:

statement1 if condition1
statement2 if condition2
statement3 otherwise

If we do this, the older programs could be converted into this new
setup.

We think it will be clearer and respond to some of the issues this group
has raised.

Let me know what you think.


Mona

[RichardJ]

On 2/11/2010 11:46:08 AM, Ted Diehl wrote:

>HOWEVER, if the person wrote the
>following in CURRENT Mathcad they would
>get
>BURNT because all the IF conditions
>would be lumped relative to the
>Otherwise condition.
>
>Prog C
>IF condition A
>IF condition 1
>IF condition 2
>Otherwise doSomething

Yes. My example was a way users can (and do) get burned by inadvertently splitting if statements with a comment. The flip-side of that coin is that they may inadvertently combine them too! The "else if" structure would fix both problems. It would also make the code understandable to someone that is not so familiar with these subtle nuances of Mathcad.

Richard

[RichardJ]

On 2/11/2010 6:26:39 PM, Ted Diehl wrote:
>I think we are all in
>agreement of the new structure
>being better!

Not only are all the users in agreement (those that have posted an opinion, anyway), we are also in agreement with PTC.

Is this a first? Should we mark our calendars?

Richard

[RichardJ]

On 2/10/2010 4:14:13 PM, Al Pergande wrote:
>I think that's clearer. A
>proper "case" statement would
>be even clearer.

For you maybe, and maybe for many of the power users. But I don't think that would be true for someone that is not familiar with case statements from another language. The if, else if, else if, ..., else structure has the advantage of reading more like straight English than any of the alternatives.

Richard

[RichardJ]

On 2/11/2010 5:33:17 PM, Al Pergande wrote:
>Oh, I agree. I'd like to see
>both clearer IF structures,
>AND a case statement.

Yes, I could go with that. If a case statement were available I would use it.

Richard

[RichardJ]

I also prefer the elseif form over the current one. It makes it very clear that the subsequent conditions are part of the same conditional statement. Some people get tripped up by the current structure, especially if they try to add a "comment" in the middle of it:

statement1 if condition1
statement2 if condition2
statement3 otherwise

means the otherwise is executed only if neither condition is true. But then if you try to be clever and comment your code with some strings:

"this is the most likely special case"
statement1 if condition1
"this is a less likely special case"
statement2 if condition2
statement3 otherwise

The if statements are then independent, and the otherwise can be executed even if condition1 is satisfied. The newer form wold not only be clearer, it would allow for such comments.

Richard

[TomGutman]

You can't convert existing if statements to the new form, the semantics are incompatible. Currently, in a series of if statements, all the statements whose conditions evaluate to true are evaluated. In ane if/elseif/else construct only one statement, the first one whose condition is true, is evaluated.

Also note that a series of expressions each followed by a condition (with a separator of if or when) is the standard way mathematicians write piecewise defined functions. Do you really wish to force a different notation, one taken from programming languages rather than mathematical usage?
__________________
� � � � Tom Gutman

[RichardJ]

On 2/11/2010 9:05:26 PM, Tom Gutman wrote:
>You can't convert existing if
>statements to the new form,
>the semantics are
>incompatible. Currently, in a
>series of if statements, all
>the statements whose
>conditions evaluate to true
>are evaluated. In ane
>if/elseif/else construct only
>one statement, the first one
>whose condition is true, is
>evaluated.

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.

>Also note that a series of
>expressions each followed by a
>condition (with a separator of
>if or when) is the standard
>way mathematicians write
>piecewise defined functions.
>Do you really wish to force a
>different notation, one taken
>from programming languages
>rather than mathematical
>usage?

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.

Second, we are talking about programming constructs. It's not possible for a Mathcad program to adhere to standard math notation all the time anyway. So if I have to make a choice between the current notation, which is closer to standard math notation, but not standard and not clear, or a new notation that is less like standard math notation, but close to standard programming notation and very clear, I'll go with the latter.

Just to make the point, take

statement1 if condition1
statement2 if condition2
statement3 if condition3
statement4 otherwise

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. The proposed new notation is completely clear.

Apart from the programming structure though, I would like to have the standard math notation available. As an option though, not as the only way to write conditional statements, because the requirements that only one condition can be met and all cases must be accounted for are too restrictive.

Richard