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
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!
I flew several times with pilot Quintal.
A super-champion landing smooooooooth.
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 !
In fact, they know this so well that they don’t have to think about it.
That's exactly what the engineer(s) for the Climate Orbiter said. Then a $330M spacecraft crashed into Mars. Oops!
OK, Richard !
I refrain more comments, but Eden did in other words:
A unit system must have a "Murphy's law peephole" [jmG]
Jean,
Not sure what you mean by "peephole" in this context. I can understand (plain) Murphy's law, for which units is one of a range of preventative measures, but I'm not sure about your peephole bit.
Philip
The Mars incident was more than just a units problem though. While that was the initial problem, many design reviews failed to find the error. The ground control crew failed to detect the many, many flight path errors that occurred enroute. The various waypoint errors were also ignored. It was very systemic operational problem caused by unfounded complacency. Had they had a Mathcad-ish data interface, the problem might have been caught. Even in a good system, unit conversions are often done, undone, done, undone, until the final product often shows several conversions back and forth. This often incurs precision errors as well as increased processing time to continually do the conversions.
TTFN
jean Giraud wrote:
>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.
Jean,
You couldn't be more right, but if I am asked in work to help with our tank design department and work to API standards most of the units are are different to those used in the British standards and therefore Mathcad can be helpful when tracing errors.
Mike
MIke Armstrong wrote:
jean Giraud wrote:
>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.
Jean,
You couldn't be more right, but if I am asked in work to help with our tank design department and work to API standards most of the units are are different to those used in the British standards and therefore Mathcad can be helpful when tracing errors.
Mike
You just have to be careful with the pre-conversion to suit API [incoherent]. What about ASME, ISO for tank design ? Tracing errors is one thing and traceability is another thing. My advice has not change since the time we had paper/pencil/tables/slide rules, just a matter to dress the working formula correctly with the front end conversions as required. At the most, checkers have slide rules and unitless calculators, eventually old DOS. The risk in this discussion is that there will be as many "unit suggestions" than there are Mathcad users and clients.
Jean
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
Absolutely.
Without units it's simply accountancy, and you see the problems thay have had with the conversion factor between 'money' and value.
MathCad doe need to take a lead on the inclusion (making available) of Angles units. It would also solve PTC's problems in Pro/e with the Torque/work confusion.
Philip
Philip Oakley wrote:
Absolutely.
Without units it's simply accountancy, and you see the problems thay have had with the conversion factor between 'money' and value.
MathCad doe need to take a lead on the inclusion (making available) of Angles units. It would also solve PTC's problems in Pro/e with the Torque/work confusion.
Philip
The angle unit is "radian" and that will not change, especially results from symbolic. True that some results might need conversions like demonstrated in the recent "Cannonball" contest. Are you suggesting that the mathematicians before Mathcad were illiterate and should have lived longer ?
jean Giraud wrote:
The angle unit is "radian" and that will not change, especially results from symbolic.
Jean,
The dimension of the "Radian", and of "Degrees", is Angle. The SI and the common mathematicians' unit of Angle is the radian. [I'm pushing this particular piece of string from the other end 😉 ]
You are right that the unit would continue to be in radians, but would change from being simply "1" to "1.Angle". Just as the second is "1.Time", and the metre is "1.Length"
Philip
Philip,
I understand what you are saying, more collabs as well. I can't whistle around earth but the entire planet can read. A unit system is a parallel computing gadget attached, and attached to same basis arithmetic operations and approximations. You complain about your project and the Mathcad unit system that you don't love so much , but what about the Process Control & Instrumentation designers: there is nothing for me ! But, using Mathcad I can build the toy box with big enough volume for the trapped kids to breath for one day or more because the "Mathcad Toy box Unit system" is just fine. A CAS with unit system is like a railway track .... the maths is the right side of the track [straight or not waving too much], the left side of the track is the unit system but in Mathcad itself and in the "Mathcad young generation of users" this left side of the track is bumpy, waving , discontinuous and many kilometers are missing. The double paradox in the Mathcad unit system is the lack of a unit converter calculator like Uconeer, coherent with Mathcad application and the other paradox is the total absence of understanding "Units" in the Mathcad design crew. The note at the end of the work sheet I have returned to Dan is paramount to implement a unit system as it deals directly with the numerical interpretation of the kernel.
Jean
The note at the end of the work sheet I have returned to Dan is paramount to implement a unit system as it deals directly with the numerical interpretation of the kernel.
Your note at the end of the worksheet shows a fundamental misunderstanding about what units represent.
To quote::
"Mathcad should be able to drop the unit whenever a function "must be dimensionless."
"An honest thinking induces that the ln( ) of a pressure should be "a pressure"."
Why do you think the log of a pressure would be a pressure? The log of a pressure, or any other quantity with units, has no physical meaning. That's why you are not allowed to do it!
Richard Jackson wrote:
Why do you think the log of a pressure would be a pressure? The log of a pressure, or any other quantity with units, has no physical meaning. That's why you are not allowed to do it!
The one area that does need resolving is the issue of the symbolic solution based issue log(p1/p2) -> log(p1) - log(p2) ==> "Must be dimensionless", rather than some form of 'explicit' such that log(p1) -> log(NumberValueOf(p1)) + log(UnitsOf(p1)), so that when p1 and p2 are entered in the same units, we get that the log(UnitsOf(p1)) - log(UnitsOf(p2)) would cancel out. [if the user gets the units wrong they get an error!]
So the log(p1) does, sort of, have physical meaning, just as 2+3i, sort of, has physical meaning in our engineering calculations. [that is they can be cancelled out!]
Philip Oakley wrote:
Richard Jackson wrote:
Why do you think the log of a pressure would be a pressure? The log of a pressure, or any other quantity with units, has no physical meaning. That's why you are not allowed to do it!The one area that does need resolving is the issue ... etc.
I agree that the log of a dimension must to be something, not just an error. At least log plots don't groan very much. But at this time in normal calculus you can't do it. In chemistry, the -log([H+]) in the water is called the pH, and it is used as unit. [H+] is the molar concentration of hidrogenions. (http://en.wikipedia.org/wiki/PH) But technically it is incorrect, you take the log of the activity, adimensional number, but with a value which is unit-dependent (http://en.wikipedia.org/wiki/Activity_(chemistry)).
Regards. Alvaro.
In Mathcad MM:
Actually, mathcad handle very well quotient of pressures
Regards. Alvaro.
... 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 .
MIke Armstrong wrote:
Jean,
See attached image.
Mike
Yes Mike, I see the image but it does not cut the mustard.
Re is not calculated so directly in flow metering sizing. DH has not landed on earth yet ? You pass me something so superfluous in my Engineering Discipline that you didn't notice the missing "DH" . The last cross check can't be checked in Mathcad, Mathcad does not have any "Flow rate" unit ! In flow metering, Re depends upon Q and vice versa , Q depends also from other factors depending upon Q . The work is multiple iterative, that's why the Re is not what you give. And that is again my irreversible point "you must know what you are doing", not sure: ask the old wolf. My recollection fails if "MassBal" [used for piping and pump sizing] had units in the mid 80's, we were mostly meeting with more conclusive facts like pipe size and pressure requirements with results hand written.
Jean.
Yes Mike, I see the image but it does not cut the mustard.
Re is not calculated so directly in flow metering sizing. DH has not landed on earth yet ? You pass me something so superfluous in my Engineering Discipline that you didn't notice the missing "DH" . .
Jean.
I did notice the missing "DH", but I have included the units for this in my image.
The only thing you have proved with your example it that units within Mathcad are of great benefit.
Mike
The Reynolds number is unitless. So, the Mathcad unit system fails.
Crap. If you put the wrong units in you get the wrong units out. Did you expect something different?
This example "Reynolds number" is extracted from Mathcad qs .
Which one?
Interesting Richard,
So, the Mathcad model qs is "crap".
Correct it and send it back to Dan .
So, the Mathcad model qs is "crap".
I couldn't say, since you haven't told me which one you are referring to.
Correct it and send it back to Dan .
If you tell me which one you are referring to and it does indeed have a bug I will fix it and send it to Mona. I can't do that if I don't know which QuickSheet it is though!
Richard Jackson wrote:
The Reynolds number is unitless. So, the Mathcad unit system fails.
Crap. If you put the wrong units in you get the wrong units out. Did you expect something different?
I'm just ever so slightly agree with Jean on this very particular point. That is that MathCAD currently is unable to track "unitless" errors. There are many systems of engineering equations that require one to remember where the system reference point is to get honest answers. For instance input referred electronic noise in very high gain amplifiers, and (as you will have hit many times Richard) the problem of measurements which are per unit angle, or per unit solid angle (Torque, radiant intensity / illumination, etc).
I continue to desire that we (MathCAD) puts that issue right by making available both and angle unit of measure, and some spare user units of measure(reference). If they can add a Currency unit for all those high frequency traders with their flash crash (6 May http://kn.theiet.org/magazine/issues/1013/flash-and-burn-1013.cfm) then they can add real angle units, and some spare for user need. (I think Jean would go the other way to solve it though; sorry Jean).
Philip