The function UnitsOf() just as Davide's UoM() returns the unit of measurement of a given argument.

The design decision has been made for both functions to return 1 if the argument expression has no explicit occurence of units, no matter if the remainder is numeric or undefined.

This means that any variable name is assumed to represent a dimensionless quantity. In paper and pencil physics, symbols always are declared to be of a certain dimension (belonging to a certain linear space), either by explicit statement or by naming conventions or by the relations defining them.

To represent this in SMath (which this post is not a vote for) you would need to be able to assign dimensions to unknowns. Then the function UnitsOf() would be expected to return the base unit of that particular dimension.

The use of UnitsOf() is usually to create unit-proof access to non-unit-aware functions, like numeric algorithms like the int(4) function.

Nobody would expect UnitsOf() to deliver a result unless the expression can be evaluated numerically, i.e. does not contain any names except units.
Thus it would be absolutely acceptable to return "unknown" or even an error message instead of 1.

My proposal is that UnitsOf() returns just itself, if the expression can't be split into a number and an expression of units (i.e. can't be evaluated numerically).

If it wants to be a bit smarter, it might do some symbolic processing like (with a undefined)

UnitsOf(a*'m) = UnitsOf(a)*'m

The question is: Is UnitsOf(something unknown)=1 what you expect in the context of a unit-aware environment?

See also discussion in SS-2318

Wrote

See also discussion in SS-2318

I think that the discussion was on how to evaluate function definitions and the function UnitsOf() was just used to illustrate the issue.
The "I can handle undefined input"-flag was introduced into the function interface to resolve that issue. It did only partly, as I demonstrate in SS-2409.

Here (and in SS-2409) I rise the issue of the behaviour of UnitsOf() outside function definition context, on the bare canvas. I am just not comfortable with UnitsOf() returning 1 when the unit in fact is unknown.

Good point. I'm agree. Fixed.



Regards.

Wrote

I think that the discussion was on how to evaluate function definitions and the function UnitsOf() was just used to illustrate the issue.
The "I can handle undefined input"-flag was introduced into the function interface to resolve that issue. It did only partly, as I demonstrate in SS-2409.

Here (and in SS-2409) I rise the issue of the behaviour of UnitsOf() outside function definition context, on the bare canvas. I am just not comfortable with UnitsOf() returning 1 when the unit in fact is unknown.

I completely agree. And I'm glad that the issue is solved.
Just wanted to mention that just because of what you've wrote, I started my comment with words "See also": this was meant to add somewhat relevant bits of information (and thus create a complete view on the problem and its history landscape when someone reads the topic), not to mark your request as a duplicate of something.

UoM does not support user "for loop" range.

Wrote

UoM does not support user "for loop" range.

This is not an issue of UoM(). You try to augment a 4 element vector by a 3 element vector. Unless SMath introduces skyline matrices, this must fail because the array dimensions do not match, as the error message correctly says.