Why is Mathcad so Keen on Units?

See paragraph two:

http://en.wikipedia.org/wiki/Gimli_Glider

They were lucky.

See paragraph two:

http://en.wikipedia.org/wiki/Mars_Climate_Orbiter

They were not so lucky!

Unfortunately, for many users, it's the only thing that Mathcad still has that makes it worthwhile keeping. There have been several forays by various putative contenders such as Wolfram's Calculation Center and SMath Studio. The former is no longer extant, but the latter is gaining in popularity, but its user interface is quite clunky.

TTFN

>The truth is, most engineers know their units. They know what unit system they use, what conversion factors are, and how to properly balance the units. In fact, they know this so well that they don’t have to think about it.<

______________________________

This is more than true on the basis that the "Application Engineer" just need to convert beforehand and use the designed formula unitless [a pure scalars]. Old Engineers design their formulas and particularly some of the governing coefficients, they design "paper pencil". For your own curiosity, open the Mathcad 8 example about the "glorious unit system" and tell me what you units you get for the Reynolds number !

BostonDan wrote: Find out from Mike Baldani why unit handling is such an important part of Mathcad’s product strategy. The Mathcad blog - http://bit.ly/aOP02c

Dan,

Mathcads unit handling is one of the main attributes which makes us engineers choose it.

It's a fantastic way to trace errors and a good way to learn the unit conversions.

Mike

... the other aspect of the reality is the advanced use of Mathcad

that can't support units while within Engineering works,

"must be unitless". Lot of projects had to be converted "unitless".

Maths are scalar and unitless and existed before Mathcad.

The Reynolds number is unitless. So, the Mathcad unit system fails.

The doctoring here is to apply a "reverse unit system" otherwise

some disastrous result might be expected. My orifice bore diameter metering

plate in a 12 " pipe can't be needle size neither as big as earth diameter.

My slide rules don't sing a song. This example "Reynolds number" is extracted

from Mathcad qs .

Hi BostonDan,

"---most engineers know their units..."

This is only partially true. Knowing your units is more than a convenient agreement; it is a powerful reality check as well.

My collegues and me agree on that the raison d'etre for MathCad is the automatic unit-checking and the simplicity of reading equations. Take away the unit check and I have only 50% of my impetus left for keeping it in use.

I know there are some guys wishing that units were a thing of the past in MathCad, but they seem to be "pure" mathematicians. For the benefit of me and my kin, i.e. engineers, who'll happily keep on tainting scalars with units, MathCad without units would be only a "prettier" Excel.

Raiko

Just one correction to Mr. Baldani's missive. The units error problem was not directly a consequence of "NASA engineers" using the wrong units; it was a problem with their subcontractor Lockheed Martin. While most of the articles appear to me to be whitewashing the problem, the Lockheed Martin team had to have gotten a requirements document specifying SI units instead of US customary units, particularly in this day and age.

What the NASA engineers did fail at was to verify compliance of the Lockheed Martin interface requirements specification (IRS) and interface data description (IDD) to the NASA team's own IRS and IDD.

While there's been much todo about XML implementations of IRS and IDD documents, they all fail short in the area of compliance testing. In fact, it's not uncommon for so-called "one-team" implementors to have incompatible versions of the almost identical XML documents.

In my mind, it's not a units issue at all, particularly given the other missteps taken by the NASA team, to wit, failure to follow up on numerous course corrections during the flight that would have identified flight control errors arising from the units problem, as well as ignoring the final approach position error that should have at least raised a pink flag that there might be a problem.

TTFN

I see that the original question remains "unanswered", at least, in the Dan concept. I go to try to answer it.

In words of Mike Baldani the key is " ... Mathcad’s unit handling is more than a convenience for engineers. It benefits collaboration and cross-organizational processes." That´s more true thinking in enterprises with the home in europe but agencies in america (and not only EUA, México too) or viceversa. Or it's true also with an isolated engineering using an equipament with specifications in a unit system which is not natural for him.

Why? Because " ... most engineers know their units. They know what unit system they use, what conversion factors are, and how to properly balance the units. In fact, they know this so well that they don’t have to think about it." Yes, but also because we need to use the common sense to check any result before remark it as a possible answer. To do it is a must handling the unit system in which we know the normal values. For example, I'm comfortable with results in Celsius, but have not idea about what meaning a value in Rankine scale. I must to make the conversion to be sure that the value fails into my experience of the "normal" values.

So, this is my idea about why mathcad is a very good tool for the diary engineering practice.

But, what about the other softwares? Maybe Mathcad isn't the best tool for the very old two things:

1. 1) find the answer for a problem.
   
2. showing to another this result in a way that
   
   1. the other guy understand
      
   2. the answer is self demonstrated as valid, just because I can make mistakes
      

Excel have a native unit converter in Analysis ToolPak. After enabling it in the addins menu, the function is CONVERT(value, unit_from, unit_to). A discussion about why is better handling units with Mathcad than with excel is, then, reduce to why is better, in general therms, with Mathcad.

Maple have also a unit package; including in version VR4. But isn't very usefull, and I don't know nobody else that use it, with the probably exception of me (acutally, I use it, but inside mathcad 11!).

Mathematica have also a unit package, but it is minimal. Actually I wrote one with some very nice features: http://library.wolfram.com/infocenter/MathSource/5511/. But the problem is when the calculations turns more complex, like integrals or differential equations, turining the unit handling in a problem more haredest that the normal unit checking. Simplification with rules inside objects that have units can turns in an obstacle run, where obstacles finally are always redundance problems.

Matlab have some few packages for handling units, but are very basics. Derive have also some definitions, but, again, can be treated as packages.

So, Mathcad isn't only a good package to complete the taskes enumerated above, is also the best, and the best by a long difference.

Regards. Alvaro.