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

[PhilipOakley]

On 12/1/2009 2:07:37 PM, Dr. D.M. Griffin wrote:
>At the risk of being branded a
>heathen and philistine I would
>like to
>say that I have been a user
>(power user?) of Mathcad since
>1990. I have
>used the programming language
>and written my share of code
>which I use
>on occasion, see my website.
>However I don't think I have
>ever seen a
>Mathcad program that was
>really useful (other than
>classroom exercises)
>or whose function(s) could not
>be carried out using existing
>Mathcad
>operators or functions more
>easily and elegantly. I
>realize this may be
>due to my particular area of
>expertise or lack thereof.
>Having said this
>we are starting a new semester
>here and I will be teaching a
>numerical
>methods course and trying to
>incorporate Mathcad
>programming, I may
>think differently after that.
>My main text will be
>Maxfield's new book
>and I will use several of the
>better known numerical methods
>texts as
>adjunct material.
>
>I still love you
>Mona...........
>
>
...
>
>�If everybody is thinking
>alike then somebody isn�t
>thinking.�
> � General George S. Patton
>
>
>

I do sympathise with those in academia, where
often algorithms are to be taught, rather than
direct solutions [Given ... Find].

When I was doing a recent postgrad maths module I
had great difficulty with attempting to programme
the various algorithms, particularly those around
the matrix decomposition and solving.

These often had loops with (for i=1:L, i<>j) etc.
I gave up trying in MathCAD. Which was a real
shame, loosing to MatLab!

Mona- I've sent in the course notes previously -
do you still have them or want another copy?

Philip Oakley

[PhilipOakley]

I think the reason is that in real engineering...
we have a need to be able to code up 'specials'
where we are doing some variant of the normal
algorithm and want to be able to do it a few
times, hence the need for the ability to put
together neat and elegant routines.

If they are ugly then it calls 'software' and you
have to do it in Matlab or C ;-(

I get to do a lot of image processing at the
moment (I do defence electro optics) which
requires many specials and repeated application of
functions. At the moment I have had to code it in
Matlab.. say no more.


On 12/1/2009 4:20:16 PM, Dr. D.M. Griffin wrote:
>P Oakley wrote:
>"When I was doing a recent
>postgrad maths module I
>had great difficulty with
>attempting to programme
>the various algorithms,
>particularly those around
>the matrix decomposition and
>solving"
>

>D.M. Griffin wrote:
>This is exactly my point, I
>too have tried to write
>Mathcad programs for various
>matrix operations, very
>difficult. However my
>question is "is it still
>necessary from
>a practical standpoint (not an
>academic standpoint) to do
>this when Mathcad and I
>presume
>Matlab and other apps have
>algorithms that do exactly the
>same thing ?" I actually go
>back
>and forth on this issue in my
>own mind depending on whether
>I'm doing consulting or
>teaching...at what
>point do we stop having
>students manually or by
>writing a program reduce a
>matrix to row echelon form ?
>
>
>
>

>
>�If everybody is thinking alike then
>somebody isn�t thinking.�
> � General George S. Patton

[StuartBruff]

On 12/1/2009 3:45:26 PM, Philip Oakley wrote:
== These often had loops with (for i=1:L, i<>j) etc. I gave up trying in MathCAD. Which was a real shame, loosing to MatLab!

do you mean, for some predefined j, the for loop would miss out i=j?

I've wondered about this as well; how about an 'exclude' keyword that tags onto the for-loop sequence? eg

for i &in; 1..L exclude i=j

== Mona- I've sent in the course notes previously - do you still have them or want another copy?

Are they interesting? Perhaps we could have go at the 'Mathcad Programming Challenges'?

Stuart

[PhilipOakley]

Yes, miss out that 'i' value when the condition is true.
It is quite common in matrix/table/array manipulations where you want to process all other rows/columns except the current one.

On 12/2/2009 4:14:16 AM, Stuart Bruff wrote:
>On 12/1/2009 3:45:26 PM, Philip Oakley
>wrote:
>== These often had loops with (for
>i=1:L, i<>j) etc. I gave up trying in
>MathCAD. Which was a real shame, loosing
>to MatLab!
>
>do you mean, for some predefined j, the
>for loop would miss out i=j?
>
>I've wondered about this as well; how
>about an 'exclude' keyword that tags
>onto the for-loop sequence? eg
>
>for i &in; 1..L exclude i=j
>
>== Mona- I've sent in the course notes
>previously - do you still have them or
>want another copy?
>
>Are they interesting? Perhaps we could
>have go at the 'Mathcad Programming
>Challenges'?
>
>Stuart

Philip Oakley C.Eng
philipoakley@iee.org

[StuartBruff]

On 12/2/2009 5:06:02 AM, Philip Oakley wrote:
== Yes, miss out that 'i' value when the condition is true.
== It is quite common in matrix/table/array manipulations where you want to process all other rows/columns except the current one.

Here's one I prepared earlier for dealing with situations like this ... note the use of the infix operator in one example.

Stuart

[PhilipOakley]

Had to scroll down to see it in V11, which then didn't use the infix 😉

While it shows it can be done, I don't think many are, and would find an embeded capability useful...

On 12/2/2009 6:40:29 AM, Stuart Bruff wrote:
>On 12/2/2009 5:06:02 AM, Philip Oakley
>wrote:
>== Yes, miss out that 'i' value when the
>condition is true.
>== It is quite common in
>matrix/table/array manipulations where
>you want to process all other
>rows/columns except the current one.
>
>Here's one I prepared earlier for
>dealing with situations like this ...
>note the use of the infix operator in
>one example.
>
>Stuart

Philip Oakley C.Eng
philipoakley@iee.org

[StuartBruff]

On 12/2/2009 7:36:13 AM, Philip Oakley wrote:
>Had to scroll down to see it
>in V11, which then didn't use
>the infix 😉

Here's an M13 image ...

Stuart

[TomGutman]

>>These often had loops with (for i=1:L, i<>j) etc.<<

That's what the continue statement is for.
__________________
� � � � Tom Gutman

[StuartBruff]

On 12/3/2009 1:41:07 PM, Tom Gutman wrote:
>>These often had loops with (for i=1:L, i<>j) etc.<<
== That's what the continue statement is for.

I confess that I'd assumed that there was some good reason for not using continue (given that Matlab has a continue statement as well) or the, perhaps more obvious, "... if i ≠ j"

Dangerous things, assumptions.

Stuart

[StuartBruff]

On 12/3/2009 5:29:31 PM, Al Pergande wrote:
>Don't forget MathCAD's
>continue operates differently
>than a Fortran continue

True, but Mathcad's continue is similar to Matlab's continue.

Matlab ---

for i=1:4
for j=1:4
if i==j,continue,end
m(i,j)=i*j;
end
end

Mathcad ---

|for i=1:4
||for j=1:4
|||continueif i=j
|||m(i,j)=i*j
|m

[TomGutman]

>>Don't forget MathCAD's continue operates differently than a Fortran continue<<

Why would I even think about FORTRAN idisyncrancies when working with Mathcad? Mathcad programming is not derived from any of the conventional languages, I do not assume that any of the constructs match.
__________________
� � � � Tom Gutman

[PhilipOakley]

I think I understand what Tom means, however there
is a subtle 'flaw' in his argument, in that the
separation between := and &lt- assignment is fully
identified by the inclusion inside or outside of a
function.
:= is used 'outside' in the worksheet at large,
while
&lt- is used 'inside' functions.

It would be my contention that that distinction
(inside/outside of function) is generally
sufficient.

The special case is that for the 'box' style
function which has := inside, then we still are
able to have a result = value displayed, and that
should be the first raw pass through that
calculation. It is not normal to have a result =
inside a function !

On 12/1/2009 1:44:47 PM, Mona Zeftel wrote:
>Tom,
>
>We are looking at this right
>now. We are keeping the
>vertical bars and =sticking
>closely to the current Mathcad
>implementation, but want to
>=improve what we can.
>
>Tom can you explain your
>objections to using := within
>programs. I =don't understand
>what you mean that ← is a
>numeric operator and has =a
>value.
>
>Thanks,
>
>Mona
>
>-----Original Message-----
>From: poweruser Listmanager
>[mailto:listmanager@collab.mat
>hsoft.com]
>Sent: Tuesday, December 01,
>2009 2:34 AM
>Subject: Programming Question
>for Mathcad Prime
>
>From: "Tom Gutman"
>
>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
>
>
>To reply:
>mailto:poweruser.131107@collab
>.mathsoft.com
>To start a new topic:
>mailto:poweruser@collab.mathso
>ft.com
>To login:
>http://collab.mathsoft.com:80/
>~listserv/



Philip Oakley C.Eng
philipoakley@iee.org

[TomGutman]

>>I think I understand what Tom means, however there
is a subtle 'flaw' in his argument, in that the
separation between := and <- assignment is fully
identified by the inclusion inside or outside of a
function.
:= is used 'outside' in the worksheet at large,
while
<- is used 'inside' functions.
<<

That is more the common usage than any inherent property. First of all, while programs are most commonly used to define functions, they are not so restricted, and it's not all that unusual for me to use a program structure in a different context.

Local variable definition is useful whenever there are multiple expressions (including subexpressions) where the order of evaluation is reasonably well known. If you are willing to trust the order of operations, you can use local variables within a single numeric expression:

a:=(b←√π)+1/b

is a perfectly valid (and potentially useful) statement.
__________________
� � � � Tom Gutman

[StuartBruff]

On 12/1/2009 1:44:47 PM, Mona Zeftel wrote:
== We are looking at this right now. We are keeping the vertical bars and sticking closely to the current Mathcad implementation, but want to improve what we can.
== can you explain your objections to using := within programs. I don't understand what you mean that ← is a numeric operator and has a value.

I use ← in a similar way to Tom, eg

d:=|a←2(c←(b←4))
|a&mid;b&mid;√c

The only improvement I'd perhaps make to ← is to allow a straight c←b←4 assignment without the parentheses around b←4.

OTOH, it could be useful to allow a:=b:=4 as well, which would make both a and b available for later use.

I have a further, related, problem with making := and ← equivalent. The distinction allows for a potential future use in distinguishing definitions that are local to an Area v definitions in the parent Area / Worksheet, ie ← makes a definition local to the scope of the structure it is used in. For example, it is useful to give examples of usage of functions defined within an Area, but this can affect regions outside the Area if names are re-used, eg:

--- Area (Closed) ----

f(x):=foo

Example:
x:=matrix(f,1000,1)

--- End of Area ---

k:=0..9
x_k:= g(k)

The previous definition of x means that the main worksheet x has 1000 elements not just the 10 the user might have been expecting.

Allowing x←matrix(...) would get round this. I don't think this would mess up any existing programs - a, b and c would, for example, still be local to the program that defines d in the case above. Making := and ← fully equivalent would deny such capability as the screams of 'backward compatibility' would prevent such later use - never fight your way into somewhere you can't fight your way out of.

What would be useful, and I have asked for before, is to be able to paste a ':=' expression into a program and have Mathcad automatically convert the ':=' into a '←' - that would make my life so much easier, as I often develop an algorithm at worksheet level before wrapping it up as a function, and it's a real PITA having to part-copy expressions.

Stuart

[PhilipOakley]

OK, so contrary to my comments relating to Tom's statement about the distinction (or lack of),
I can see that when using an Area as a function we could get problems.

The &lt- arrow is a visual clue that the variables value will 'disappear' after exiting the current code zone (Area/Box/Function).
The := tends to suggest permanance.

Which proably brings me back to being the same point I made relating to Tom's comment. The two symbols are used in mutually exclusive cases, so are simply visual cues. [As long as the Mutual Exclusion is maintained]
P.

On 12/2/2009 3:54:23 AM, Stuart Bruff wrote:
>On 12/1/2009 1:44:47 PM, Mona Zeftel
>wrote:
== We are looking at this right
>now. We are keeping the vertical bars
>and sticking closely to the current
>Mathcad implementation, but want to
>improve what we can.
== can you explain
>your objections to using := within
>programs. I don't understand what you
>mean that �� is a numeric operator
>and has a value.

I use �� in a
>similar way to Tom,
>eg

d:=|a��2(c��(b��4))
|a&m
>id;b&mid;��c

The only improvement
>I'd perhaps make to �� is to allow a
>straight c��b��4 assignment
>without the parentheses around
>b��4.

OTOH, it could be useful to
>allow a:=b:=4 as well, which would make
>both a and b available for later use.

I
>have a further, related, problem with
>making := and �� equivalent. The
>distinction allows for a potential
>future use in distinguishing definitions
>that are local to an Area v definitions
>in the parent Area / Worksheet, ie
>�� makes a definition local to the
>scope of the structure it is used in.
>For example, it is useful to give
>examples of usage of functions defined
>within an Area, but this can affect
>regions outside the Area if names are
>re-used, eg:

--- Area (Closed)
>----

f(x):=foo

Example:
x:=matrix(f,10
>00,1)

--- End of Area ---

k:=0..9
xk:=
>g(k)

The previous definition of x means
>that the main worksheet x has 1000
>elements not just the 10 the user might
>have been expecting.

Allowing
>x��matrix(...) would get round this.
>I don't think this would mess up any
>existing programs - a, b and c would,
>for example, still be local to the
>program that defines d in the case
>above. Making := and �� fully
>equivalent would deny such capability as
>the screams of 'backward compatibility'
>would prevent such later use - never
>fight your way into somewhere you can't
>fight your way out of.

What would be
>useful, and I have asked for before, is
>to be able to paste a ':=' expression
>into a program and have Mathcad
>automatically convert the ':=' into a
>'��' - that would make my life so
>much easier, as I often develop an
>algorithm at worksheet level before
>wrapping it up as a function, and it's a
>real PITA having to part-copy
>expressions.

Stuart



Philip Oakley C.Eng
philipoakley@iee.org

[Fred_Kohlhepp]

FOr myself, the vertical bar(s) are verey useful to recognize and follow the programming, I would be sorry to see them disappear.

It's not clear to me that this is any improvement; the opening and closing brackets merely indicate that someone comfortable in C programming is near the top of the design group. What does that add?


Fred Kohlhepp
fkohlhepp@sikorsky.com

[StuartBruff]

On 12/2/2009 4:27:29 PM, Mona Zeftel wrote:
>We are keeping the vertical bars. The other was a proposal that we considered, and due to the feedback from this forum we decided not to do.

Mona,

Is there any chance you could post the currently proposed spec on this forum, so that we get a better picture of what the Prime programming capability is now intended to comprise?

Thanks,

Stuart

[PhilipOakley]

Show at least a view about the lead concept and
areas of potential compromise/adjustment then ? ;-
)

Surely if the "specs" aren't final then they are
still highly flexible, so don't actually tell
people of definitive commitments.
The easiest way I find around this is to retitle
the document to a non-provocative title!
It is the classic 'consultation' conundrum.

Philip

On 12/4/2009 3:27:15 PM, Mona Zeftel wrote:
>I cannot post specs, since
>they are not final, and this
>entire group is
>not under non-disclosure.
>
>I will be posting ideas we are
>looking at and asking for
>early feedback.
>
>Mona
>
>-----Original Message-----
>From: "Stuart Bruff"
>
>On 12/2/2009 4:27:29 PM, Mona Zeftel
>wrote:
>>We are keeping the vertical bars. The other was
a proposal that we
>considered, and due to the feedback from
>this forum we decided not to
>do.
>
>Mona,
>
>Is there any chance you could post the
>currently proposed spec on this
>forum, so that we get a better picture
>of what the Prime programming
>capability is now intended to comprise?
>
>Thanks,
>
>Stuart


Philip Oakley C.Eng
philipoakley@iee.org

[mzeftel]

Thank you all for your feedback so far. This is really helpful, and I'm
capturing it.

Things that are already in the new spec include:
1. Being able to type keywords.
2. Breaking programs easily across pages.
3. Adding comments.
4. Ease of editing, nesting.
5. Use of := for definition instead of <- for consistency.
6. Disabled regions inside programs
7. Backwards compatibility so that Mathcad 14 (and lower TBD) programs
convert to Prime programs.

More to come.

Mona

[RichardJ]

On 11/24/2009 7:07:18 PM, Stuart Bruff wrote:
> 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

>see thread
>http://collab.mathsoft.com/read?114150,1
>2

I had forgotten about that discussion. I have also asked for extending the capabilities of areas, including locally scoped variables and inputs/outputs. Allowing those extra keywords inside areas would be useful too. I think it's a different topic to this one though (but closely related, of course).

Richard