Beware leaky "stack" function for mixed unit matrices

[GeoffD]

Beware of using the "stack" function with mixed unit matrices containing zero terms without units. Prime seems to "leak" the units from another term to the unitless zero terms: 

Given that Prime is fairly pedantic about using units  - even on zero terms- subsequent computations using 0.N instead of 0 will fall over.

This can unwittingly happen when radians are used, and you expect the value to remain a pure ratio. The get around is to ensure radians are inserted at source - even though Prime strips them off in subsequent results:

If you copy and paste this result, into another expression, the rad unit will get swapped out for another:

However, this is of no help if the zero value is not an angle e.g. a zero count value.

[Werner_E · Accepted solution]

I agree that its a nasty and annoying behaviour and it looks like some leftover from the former SUC (static unit check) which we had in MC15.

You may want to look up the explanation for the two new "pseudo-units" "zero" and "Zero" in the documentation. The doc calls them units, but they are labelled as units !?

You can avoid the undesired behaviour if you use zero (note the lower case z) instead of 0.

Nonetheless - unpleasant and non-intuitive.

I would rather like to get an error if I try something like 1m + 0 =  instead of  1m +0 m =

I guess it would make more sense if "0" would be treated as "zero" and not as "Zero".

BTW, it has nothing to do with the stack function. Simply evaluate dum after you defined it and you will see the same effect.

From the Migration Guide:

Note
To provide more control over how numeral 0 should behave, PTC Mathcad
Prime 9.0.0.0 provides two built-in constants:
• zero (lowercase) — Represents dimension less 0. For example, zero + 1m
yields an error whereas 0 + 1m = 1m
Use variable zero to ensure that the quantity is always checked for correct
dimension, even when it has a magnitude of 0.
• Zero (uppercase) — Represents 0 of any quantity. It assumes whatever unit
is required by the computation. For example, Zero*m + Zero*s = 0
Use variable Zero to simulate compatibility with legacy Mathcad
treatment.
It is recommended that you always specify the desired unit with every magnitude
in mixed unit expressions.

EDIT: Concerning the (pseudo)units rad and deg
You don't need to copy & paste. If you use an inline evaluation when defining the matrix you can experience the same undesired effect.

[GeoffD]

Thanks for pointing out the existence of zero and Zero.

Whilst we can type either type of zero, is there a simple way of ensuring the right type of zero is visibly inserted into a generated matrix?

In mixed matrices, where unitless zeros might occur, is it better to artificially assign a unit to avoid this happening?

The stack function aspect occurred when running code to modify values in a mixed matrix. The workaround was to use a for loop to change things element by element - that way the "leakage" was avoided.

Concerning the editing issue, It seems that copy and paste is generally problematic. I invariably use variables to transfer values now as you suggest. In particular, copying matrices where only the visible number is copied not the full accuracy value (unlike, say Excel.). Also, the reported issue concerning the copying and pasting of differential equations. First-time users should be alerted about this practice - "what you see is sometimes different to what you get"

Thanks!

[Werner_E]

---

@GeoffD wrote:

Thanks for pointing out the existence of zero and Zero.

---

Its actually hard to find. Not sure why the information about zero and Zero is hidden in the Migration Guide and is not available in the normal help pages.

---

Whilst we can type either type of zero, is there a simple way of ensuring the right type of zero is visibly inserted into a generated matrix?

I don't think so

---

In mixed matrices, where unitless zeros might occur, is it better to artificially assign a unit to avoid this happening?

---

Adding artificial units like "rad" or using "zero" can help but as long as the number 0 is not treated like "zero" (and not like "Zero" as it seems to be the case now), you may still fall into this trap now and then.
Especially when you copy results or use inline evaluations like in the following example

The static unit check in MC15 had its advantages and was often convenient, but it also had its huge drawbacks. So generally I appreciate that Prime has switched to dynamic unit checking again, but IMHO concerning the treatment of the number 0 it was badly implemented.

[GeoffD]

Thanks for the further insight!