topic Re: Things I wish they'd taught me about Mathcad in Mathcad

Things I wish they'd taught me about Mathcad

RantEng — Wed, 03 Dec 2025 18:22:42 GMT

So, I'm about to introduce Mathcad to a new bunch of Mechanical Engineers. I've used Mathcad my whole career (recently retired). To those new to the software, I demonstrate how I use it to document and refine calculations.

In the days when I was in the office, I'd sit with Engineers individually and show them several things that are not clearly explained upfront (all the different meanings of the = symbol). Managing subscripts and indexes, also spotting the difference between them.

So, thinking of all the things we learned the hard way, let's think of a collection of what you wish they'd taught you upfront. Suggestions?

Bob Adams, aka RantEng

Re: Things I wish they'd taught me about Mathcad

DJNewman — Wed, 03 Dec 2025 18:57:50 GMT

The first thing you should do is set up a default template, and the first thing you want to do in that template is set up Mathcad in landscape mode. Mathcad is so, so much better in landscape.

(Unless you're one of those people that rotates their monitor.)

Edit: Landscape mode is on my mind for lots of reasons recently, but it really took me years to know to switch to landscape mode, and then even longer to actually do this in my default template.

Re: Things I wish they'd taught me about Mathcad

Derbigdog — Thu, 04 Dec 2025 19:08:47 GMT

These are for PRIME

The difference between setting up a RANGE and a MATRIX in Mathcad.
Defining units
Things you can't do when setting up a PLOT.
Being able to insert a math function in a text block
Formatting HEADERS and FOOTERS

There are others but these stand out for me.

The problem for us old timers is we learned many of these things in the original Mathcad and then had to learn them for PRIME.

Re: Things I wish they'd taught me about Mathcad

ppal — Fri, 05 Dec 2025 02:00:48 GMT

Eg:

Re: Things I wish they'd taught me about Mathcad

RantEng — Fri, 05 Dec 2025 20:04:46 GMT

I've been using Mathcad for 38 years and I still fall into the trap of trying to use to use a counting range as a vector.

Bob

Re: Things I wish they'd taught me about Mathcad

StuartBruff — Sat, 06 Dec 2025 02:15:27 GMT

@ppal wrote:

7 Range Variables are Iterators, Not Vectors.

This is a subtle but vital distinction.

Defining i:= 1...10 does not create a vector of numbers. It creates an instruction to iterate.

You cannot square a range variable (i²) and expect a list of squared numbers unless you define a function or vector first.

@RantEng wrote:

I've been using Mathcad for 38 years and I still fall into the trap of trying to use to use a counting range as a vector.

Bob

First point:

And, from years of experience on this forum, that is why when I proposed the Zen of Mathcad, I specifically highlighted Shishin 1 and Shishin 30

MEP 00 – The Zen of Mathcad

1. >>> Range Variables Are Not Vectors <<<.
2. Think in two dimensions for layout and data.
3. Be like Zathras-- cover all possibilities. Zathras does not want other people being confoosed.
4. Yesterday's friendly hard limits are today's enemies.
5. Beautiful is better than ugly.
6. Explicit is better than implicit.
7. Unless implicit is better.
8. Simple is better than complex.
9. Complex is better than complicated.
10. Flat is better than nested.
11. Except where it isn't.
12. Sparse would be nice.
13. Readability counts.
14. Now is better than never.
15. Although never is often better than *right* now.
16. Functions should work over any data type.
17. Except where there is no meaning.
18. Special cases aren't special enough to break the rules.
19. Although practicality beats purity.
20. Errors should never pass silently.
21. Unless explicitly silenced.
22. But Exceptions should be Exceptional.
23. In the face of ambiguity, refuse the temptation to guess.
24. But see Zen 14.
25. There should be one-- and preferably only one --obvious way to do it.
26. But don't let that stop you doing it another way.
27. You'll probably need to-- this is Mathcad.
28. If the implementation is hard to explain, it's a bad idea.
29. If the implementation is easy to explain, it may be a good idea.

30. Yes, vec helps, but >>> Range Variables Are Still Not Vectors <<<.

Please feel free to add your own Shishin or comment on the originals.

Stuart

Shishin (指針) translates as 'guideline' but also as 'compass needle'.

https://community.ptc.com/t5/Mathcad/MEP-00-The-Zen-of-Mathcad/m-p/1040983#

Re: Things I wish they'd taught me about Mathcad

RantEng — Mon, 08 Dec 2025 13:53:37 GMT

That's brilliant

Re: Things I wish they'd taught me about Mathcad

StuartBruff — Fri, 12 Dec 2025 04:25:04 GMT

IMO, users could benefit from a decent article written by a PTC development engineer. I say a PTC engineer, because an explanation of what is actually going on under the hood might go some way towards clarifying a range's and a range variable's behaviour, particularly with respect to differences between ranges in Mathcad Prime and Legacy Mathcad (which is where many of us cut our Mathcad teeth).

For instance, I'm not quite sure *I* see things the same way that *you* see them - that is not to say I'm right and you're wrong, it's just that my experiences have led me to construct my own "myths" about how ranges and range variables work. (I've highlighted your comments in brown)

Shishin 4 is why I added the note about a range's limitation on the number of values. I've had numerous debates over the decades about "reasonable" limitations, each of which has only reinforced my feeling that there are no such things. The megabyte of yesterday isn't even small change today, and increases in performance lead to increases in demand.

Stuart

Note: the function vec` referenced above is not Mathcad 11's built-in function vec. I regard the latter as flawed, as it doesn't behave in the same way that almost every other range-to-vector conversion function has behaved for the past 20 years. I don't mind the additional arguments, but it's the functional omissions that annoy me. The function vec has 'traditionally' non-recursively converted its argument into a vector, no matter the type (I've also made frequent use of a version of vec that recursively flattens nested arrays).

For example, scalars, strings, and functions become single-element vectors, ranges get expanded into vectors, and - importantly - matrices get flattened into vectors, as per the mathematical definition of vec (https://en.wikipedia.org/wiki/Vectorization_(mathematics)).

The official Mathcad 10 workaround for the change in evaluation assignment behaviour did all of the above. Mathcad 11's vec, however, only converts ranges to vectors, ignores vectors, and throws an error in all other cases.