Programming Question for Mathcad Prime

[mzeftel]

We are looking at the programming for Mathcad Prime, and are considering several options. One is to keep programming pretty much as it is in Mathcad 14, and enhance it with user suggestions.

Another option is to put programming inside a box like the Solve Block box in Mathcad Prime. That would make it easier to do some things that users have been asking for:

* break up programs into blocks
* make programs look like programs in other applications
* break programs over pages
* add comments on the same line
* easier to edit a program
* could have disabled regions in program (not just the entire program.

Disadvantage: could not use program box inside an equation, like 1 + program. Perhaps we could do something special like if.

Another option is for programming to be more like it is in Mathcad currently, with it being a special type of equation.

Advantages:
* More like previous Mathcad
* can be used inside another equation
* more restrictive (so easier for new users to learn)

Disadvantages:

* Can not be easily broken across pages
* harder to edit
* can not easily add comments on the same line

We'd like to go with box version, but want to check if any of you see problems with it. Do you use inline programs inside equations? Whichever way we go, we would ensure backwards compatibility with previous programs. I've been recording requests, both recently and from previous requests, so we will implement as much as we can.

Let us know what you think.

Mona

[RichardJ]

On 11/23/2009 2:12:53 PM, Mona Zeftel wrote:
>We are looking at the
>programming for Mathcad Prime,
>and are considering several
>options. One is to keep
>programming pretty much as it
>is in Mathcad 14, and enhance
>it with user suggestions.
>
>Another option is to put
>programming inside a box like
>the Solve Block box in Mathcad
>Prime. That would make it
>easier to do some things that
>users have been asking for:
>
>* break up programs into
>blocks

In what way? Do you mean a program could span more than one box?

>* make programs look like
>programs in other applications

Depending on what you have in mind, I don't know if I like that idea. First and foremost, statements in Mathcad programs should look like other statements in Mathcad. I can create constructs in a Mathcad program that do not exist in any other language I have seen (for example direct assignment of a vector of numbers to a vector of variables). Don't take that away in a quest to make Mathcad programs look like FORTRAN! As another example, I would also much prefer to keep the current for loop statement than have something like "for i=1 to 20 step 2". The current for loop statement looks mostly like a range variable definition. If I was going to change it in any way at all I would make it look exactly like a range variable definition!

The things I really dislike at the moment are:

1) The way the if and on error statements look if they only apply to one line. The "if" is after the statement it applies to, which is not logical either as simple English or compared to any other programming language, or to the way it looks if you have two or more lines. If you nest if and/or on error statements it is even worse. It is impossible to figure out what it's doing!

The fact that you can't type the statements. Why is this the case?

The fact that I have to add a line before adding any statement. It's such a PITA that I usually add about 10-15 lines, then just delete the unnecessary ones at the end.

When I add lines to a program it doesn't push subsequent regions down.

The lack of comments on the same line. It was suggested in the recent thread on programming (which I never responded to because I was travelling in Asia) that we have the ability to put more than one statement on a line. I agree. If we have that then the in-line comments are taken care of.

The fact that I can't break out of a nested loop without setting flag variables. I would like "break,n", which will break out of n levels, whether they are loops, if statements, etc.

>* break programs over pages
>* add comments on the same
>line

Why would this not be possible if we don't have the box? It can't be that hard to add a statement delimiter that would allow multiple statements on one line.

>* easier to edit a program

Why would it make it easier to edit a program?

>* could have disabled regions
>in program (not just the
>entire program.

That would be nice, but why is this feature not possible if we don't have a box?


>Disadvantage: could not use
>program box inside an
>equation, like 1 + program.
>Perhaps we could do something
>special like if.
>
>Another option is for
>programming to be more like it
>is in Mathcad currently, with
>it being a special type of
>equation.
>
>Advantages:
>* More like previous Mathcad
>* can be used inside another
>equation
>* more restrictive (so easier
>for new users to learn)
>
>Disadvantages:
>
>* Can not be easily broken
>across pages
>* harder to edit

Why?

>* can not easily add comments
>on the same line

Why?

Richard

[PhilipOakley]

I can't quite visualise 'the box' concept. Picture?
Philip Oakley

[RichardJ]

On 11/24/2009 6:17:49 PM, Philip Oakley wrote:
>I can't quite visualise 'the
>box' concept. Picture?

I think the idea is that they would look like a solve block does in Prime. I also have a hard time translating that to exactly what a program would look like though.

Richard

[StuartBruff]

On 11/24/2009 7:06:34 PM, Richard Jackson wrote:
>> On 11/24/2009 6:17:49 PM, Philip Oakley wrote:
>> I can't quite visualise 'the box' concept. Picture?
== I think the idea is that they would look like a solve block does in Prime.

Yes, I think that's the general idea.

== I also have a hard time translating that to exactly what a program would look like though.

Possibly something along the lines of my recent posting?

Stuart

[StuartBruff]

On 11/23/2009 2:12:53 PM, Mona Zeftel wrote:

== We are looking at the programming for Mathcad Prime, and are considering several options. One is to keep programming pretty much as it is in Mathcad 14, and enhance it with user suggestions.
== Another option is to put programming inside a box like the Solve Block box in Mathcad Prime. That would make it easier to do some things that users have been asking for:

I'm tempted to suggest that both forms are desirable.

== Disadvantages:
I agree with Richard ...

== * Can not be easily broken across pages

Why not? I'd settle for breaking between 2 adjacent lines.

== * harder to edit

So make it easier 🙂

== * can not easily add comments on the same line

I can't see what the problem is here. There are many ways to skin this particular cat, eg a comment operator (displayed as, say, //) that appends itself to the end of the current line and presents a placeholder for the user to type a comment into. I vaguely remember there being a thread that presented several options for commenting existing code; perhaps one of these could be re-evaluated with the intent of making it look neater.

The User should be the prime focus of any development work in terms of 'ease' - but these comments tend to give the impression that developer difficulties are influencing things.

== We'd like to go with box version, but want to check if any of you see problems with it.
How will you handle loops - there is a clear need to distinguish between evaluating a set of equations sequentially for a given index (for & while loop) as opposed to evaluating each equation for the complete range of indices (range-variable evaluation)

In addition, there would still need to be a capability to block off if..otherwise sub-areas.

For example see http://collab.mathsoft.com/read?63068,77 for a brief discussion of looping within boxes - the attached worksheet might be worth looking at: http://collab.mathsoft.com/upload/Worksheet%20Looping%20Variant%201.mcd


== Do you use inline programs inside equations?

Yes. I use them to carry out pre-processing on arguments to functions. A common use in M13/M14 is local function definition to allow a multi-argument function to be parameterized for 3D plot input (eg, if f(a,x,y) then write λ(x,y)←f(3,x,y) in a plot placeholder).

I've already posted some thoughts on 'boxes' (although I called them Rectangular Areas). I envisaged that they would act slightly differently to the way Spirit implements Solve boxes, eg

- the box would return a result, either the last one or via a specific 'return' statement
- the box would therefore allow itself to be assigned to a function definition, ie acting pretty much like a Mathcad 'component'.
- a box would, unless it's the rhs of a function definition, allow direct manipulation and creation of 'higher level' variables; the local definition operator could be used to limit the scope of variables to a box or its sub-boxes. Note: this would mean the retention of both the ← and := operators.

see thread http://collab.mathsoft.com/read?114150,12

which contains the following worksheets:

http://collab.mathsoft.com/upload/Hayward%20Chaotic%20Iteration%20v3%281%29.mcd
http://collab.mathsoft.com/upload/ICW%20Example%281%29.mcd
http://collab.mathsoft.com/upload/Rectangular%20Area%20demonstration%202%281%29.mcd

[SteenGroðe]

After experiencing Prime I tend to be a bit nervous on changes. So despite the box-thing sounds interesting I will like to experience an implementation before I decide how good the idea is.

And I believe there is some more basic things to fix in the first place:
a) one line if (not expecting another if or an otherwise

b) more designs to the line eg. {

c) an option to translate Mathcad code to C++ and to make user dll's this way

d) ability to work with symbolic mathematical expressions, so we can make programs that extends the parser. So far the only way I know to do this is to write expressions as strings so what is needed is maybe just a conversion between Mathcad expression to string.

Steen Gro�e

[SteenGroðe]

BTW Take a look at Scratch http://scratch.mit.edu/ to see how easy programming can be made.

Steen Gro�e

[StuartBruff]

On 11/24/2009 7:07:18 PM, Stuart Bruff wrote:
==On 11/23/2009 2:12:53 PM, Mona Zeftel wrote:
== We are looking at the
>programming for Mathcad Prime, and are
>considering several options. One is to
>keep programming pretty much as it is in
>Mathcad 14, and enhance it with user
>suggestions.
== Another option is to
>put programming inside a box like the
>Solve Block box in Mathcad Prime. That
>would make it easier to do some things
>that users have been asking for:

>> For example see http://collab.mathsoft.com/read?63068,77 for a brief discussion of looping within boxes - the attached worksheet might be worth looking at: http://collab.mathsoft.com/upload/Worksheet%20Looping%20Variant%201.mcd

Although I may have suggested an area approach to implementing loops and conditionals at worksheet level, I would prefer to have something that took at more mathematical view.

I think it's important to keep in mind the whiteboard/document view of what Mathcad is, rather than try to make it look like A N Other programming language (even though that's what it really is).

Stuart

[mzeftel]

Here's an example of the Programming inside a box concept, like the solve block in a box feature in Mathcad Prime 1.0 Preview.

Mona

[RichardJ]

On 11/25/2009 11:42:11 AM, Mona Zeftel wrote:
>Ted,
>
>The myFunc(x,y,z) :=
>thisNewProgramBoxThingy is
>inside the box, in the
>picture I posted. The other
>things you mentioned are
>details. The long
>line in the current programs
>would be replaced by the
>gridlines in
>Mathcad Prime, so you can
>indent using the background
>grid. We are
>adding aligning features.
>
>Mona

Like Ted, I don't get it. What's the function name? What are the arguments to the function?

Richard

[RichardJ]

It's a bit easier if the image is embedded in the body of the post:



Some immediate thoughts:

1) The opening and closing brackets for a block of code should be vertically aligned. The way you have it now it is very difficult to visualize the structure.

2) How is the indent handled? Did you create the indent levels by manually aligning the various statements, as would be necessary if this were to be typed in to a Mathcad worksheet? If the answer to that is yes, then it needs to be changed. It must be easy to create indent levels, and reasonably difficult to accidentally screw them up my moving a statement.

3) Like Ted, I much prefer the current lines as a way to show blocks of code compared to the opening and closing brackets. Yes, other languages use brackets, but those languages are designed to be typed in plain text. Mathcad has no such restriction. The lines are both clearer and more compact.

Richard

[TomGutman]

Ah, using C syntax rather than an extension of the standard mathematical piecewise function definition. I expect that the developers like it, because they are C programmers, not Mathcad users.

I don't much care for it. My experience with C is that keeping the indentation and nesting levels straight is a PITA. If you make the indentations large, programs quickly run off the right edge of the sheet. If you make it small, it becomes difficult to visually see corresponding indents in widelyu separated sections. I find that the program bar works very well, giving a clear, easy to see indication of the nesting while using relatively little screen space.

I also use program structures as values within an expression (rarely at the worksheet level, usually within a program) and would not want to give that up.

While there's a lot to be said for eliminating the dual assignments (:=, ←) this requires great care. The two are not anywhere near equivalent, having, for starters, very different syntax. := is a statement definition, can exist only as a top level operator, and has no value; ← is a numeric operator that can be used anywhere an expression can be used and has a defined value.
__________________
� � � � Tom Gutman

[TomGutman]

The expression a←b is an expression with a value, and can be used anywhere a value is needed. An example I can write c←3+(a←b), which assigns to c three more than the value assigned to a. I cannot do the same with :=. c:=3+(a:=b) is invalid (if you can even input it).
__________________
� � � � Tom Gutman

[TomGutman]

>>Huh? You can type c <-- 3+ (a <--B) in a wok sheet (not a programming stru=cture)? Doesn't work for me...<<

Yes, you can type that as a standalone expression. Doesn't make much sense to do so, since c is defined as a local variable and so the assigned value disappears after the statement is completed. This form is really only useful within a multi-line program structure, where later expressiions use the local variable c.

But there is really no distinction between an expression and a program structure. A program structure is just an expression that happens to use the sequence operator (entered with ], represented by the vertical bar). Local variable assignment can be used in any expression, whether or not it uses the sequence operator, although it is only useful if you can use the assigned value later in the expression. One common use of local variables without a sequence operator (program bar) is with the array constructor, where one expression can define a local variable that is used in later expressions (you do need to keep careful track of the sequence in which array constructor elements are evaluated, and that sequence is not the same in all versions of Mathcad).
__________________
� � � � Tom Gutman

[PhilipOakley]

On 12/1/2009 3:28:42 PM, Tom Gutman wrote:
>The expression a←b is an
>expression with a value, and
>can be used anywhere a value
>is needed. An example I can
>write c←3+(a←b),
>which assigns to c three more
>than the value assigned to a.
>I cannot do the same with :=.
>c:=3+(a:=b) is invalid (if you
>can even input it).
>__________________
>� � � � Tom Gutman

while it is currently invalid to use the := embedded assignment, it doesn't make it 'wrong'.
The fact that you can do it in a function shows it
is possible (as a calculation). It's just that it
feels 'not nice' in one case, and 'acceptable' in
the other. As Mr Spock would sat "illogical" 😉

Philip Oakley

[TomGutman]

>>while it is currently invalid to use the := embedded assignment, it doesn't make it 'wrong'.<<

It is invalid and not supported by Mathcad. Mathcad defines the := as defining a statement, and so restricts its usage to that context. Certainly one could define it differently, with different restrictions. But that is not a simple task, and would need considerable thought and great care to consider all the implications of a different definition (and Mathcad development traditionally has not done a good job of considering the ramifications of changes -- many problems have been caused by a developer making a change that fixes the immediate problem the the developer was charged with solving while causing significant problems in other areas of Mathcad that the developer never thought about (and possibly didn't even know about -- I have the feeling that Mathcad developers, by and large, are not actually Mathcad users). One area is the way worksheet assignment interacts with range variables. Not straightforward at all.
__________________
� � � � Tom Gutman