Hello Dan,

In[759]:= D[Quantity[5, "Meters"], Quantity[t, "Seconds"]]

Out[759]= Quantity[0, 1/("Seconds")]

attaching a unit to t is obviously the thing to do. But in my opinion the outcome should read

Out[759]= Quantity[0, "Meters"/"Seconds"]

Francis, I don't think that my solutions to your examples contain 'pages of extra code' over your presentations in your earlier posting. To me they seem about the same length or maybe even shorter. And they work. In my opinion it's not good practice to teach students to mix input values and units into their equations. If one looks into any advanced physics book or paper they just don't do it. If one plans to run them through algebraic derivations the units act like a pack of barking dogs. Units are not necessary there and they contribute nothing there.

(You talk about Mathematica as being code. Mathematica is NOT a programming language. It is a new active and dynamic medium for developing and publishing ideas that have a mathematical content. We have to learn how to use it - even the developers. If you want to be a programmer use MatLab, if you want to be a scientist/intellectual use Mathematica.)

If you are truly interested in advancing STEM education then I can show you how you can make a significant contribution if you wish to contact me by email through my profile page.

On an unrelated note, in the early 80's ('81 to be exact) I worked on a Jovial compiler project. It was a subcontract from Singer I believe, and intended for use in simulators for training pilots. I have since seen one or two such simulators in a museum (maybe I also belong in a museum...)

I appreciate everyone's time on this issue, so dear to my heart!

So, please, show me the errors of my ways, or at least the errors in my syntax.

Please consider this calculation again, that requires Integrate.

r0Vec = {Quantity[0, "Meters"], Quantity[0, "Meters"]};
r1Vec = {Quantity[1, "Meters"], Quantity[0, "Meters"]};
v0Vec = AngleVector[{Quantity[2.8, ("Meters")/("Seconds")], 0 Degree}];
v1Vec = AngleVector[{Quantity[0, ("Meters")/("Seconds")], 0 Degree}];
aVec = {ax, ay}; 
m = Quantity[0.45, "Kilograms"];
g = Quantity[9.8, ("Meters")/("Seconds")^2];
Fw = m*g;
FwVec = AngleVector[{Fw, 270 Degree}];                                             
FkVec = AngleVector[{Fk, 180 Degree}];
FnVec = AngleVector[{Fw, 90 Degree}];                                              
RVec = FkVec + FnVec + FwVec;                 

This code will explode because of the way I have defined aVec. This much we can agree on. It will cause Integrate and Plus to return Quantity based errors regarding mismatched units.

aVec = {ax, ay};

So, the question now is:

How do I correct this definition?

What is the proper syntax, if you will?

As mentioned above, we could change the definition of aVec to the following:

aVec = {Quantity[ax, ("Meters")/("Seconds")^2], 
   Quantity[ay, ("Meters")/("Seconds")^2]};

And if we do so, and evaluate the following cell:

r0Vec = {Quantity[0, "Meters"], Quantity[0, "Meters"]};
r1Vec = {Quantity[1, "Meters"], Quantity[0, "Meters"]};
v0Vec = AngleVector[{Quantity[2.8, ("Meters")/("Seconds")], 0 Degree}];
v1Vec = AngleVector[{Quantity[0, ("Meters")/("Seconds")], 0 Degree}];
(*aVec={ax,ay};*) 
aVec = {Quantity[ax, ("Meters")/("Seconds")^2], 
   Quantity[ay, ("Meters")/("Seconds")^2]};
m = Quantity[0.45, "Kilograms"];
g = Quantity[9.8, ("Meters")/("Seconds")^2];
Fw = m*g;
FwVec = AngleVector[{Fw, 270 Degree}];                                             
FkVec = AngleVector[{Fk, 180 Degree}];
FnVec = AngleVector[{Fw, 90 Degree}];                                              
RVec = FkVec + FnVec + FwVec; 
NSolve[{RVec == m*aVec, 
  r1Vec == r0Vec + Integrate[v0Vec, Quantity[t, "Seconds"]] + 
    Integrate[Integrate[aVec, Quantity[t, "Seconds"]], 
     Quantity[t, "Seconds"]], 
  v1Vec == v0Vec + Integrate[aVec, Quantity[t, "Seconds"]]}, 
  {t, ax, ay, Fk}]                                  

We get, in V12, the following output:

{{t -> 0.714286, ax -> -3.92, ay -> 0., 
  Fk -> Quantity[1.764, "Newtons"]}}

Which is perfectly correct, EXCEPT there are no units for t and ax.

Why is this?

Is this the wrong syntax for the definition of aVec?

Or is this simply the best one can hope for in V12?

Thanks, - Joe

All code examples are in the attached notebooks. The examples are all "three cells" in length. Practically "one-liners". I can not demonstrate these issues with less code. Because I using "built in" Mathematica typesetting, like the integral sign, there is now way to show such code on this website, short of an attached notebook.

It appears the "unit-less" definitions of variables, like the components of the acceleration vector (shown above and below) are causing the bulk of the problems. As the following example shows, the same unit-less definitions work fine if the Integrate function is not involved. Hence, the Quantity BUG seems related to the Integrate function.

In a last ditch effort to illustrate the shortcomings in V12 and Quantity function, I have attached a notebook below that codes a solution to a single problem in Newtonian Mechanics.

I show three implementations, two in V12 and one in V4.

Only the V4 version works in a complete and correct sense. Interestingly, the V4 version contains 1/2 the "keystrokes" to code as the V12 version. Clearly was V4 superior to V12 in this regard.

I find the Quantity function in V12 prevents a complete solution.

This seems quite ironic, since the intention of the Quantity function was to add "units" to Mathematica, but the actual implementation of the Quantity function makes it impossible to correctly use units in V12 in a complete, accurate and easy way. Instead, it merely doubles the keystrokes necessary to express a problem, up the chances of syntax errors, and prevents Solve/NSolve from correctly outputting units to some variables.

JPEGS below are shown for typesetting and additional commentary. All code is contained in the notebook, even the V4 (which of course can not be "re-evalutated" but is included, with the original V4 output, in CodeText cells).

Attachments:

The Quantity BUG...nb

Again, sorry for the JPEG. It is just that V4 is a "dead language" and this is my only readable options for showing how easy working with "home-rolled" units was in V4. I could easily do things in V4 that are next to impossible in V12. How could that be? Would it not be better to have Quantity as a "Package" that could be used or ignored, at the discretion of the programmer? Just a thought!

That is, would it not have been better for Wolfram to get a foundational concept like Units working completely, and flawlessly, before adding to that weakness new objects, entities, alphas, betas and bags of potatoes? ;-)

I understand. Thanks for your time and input.

My example notebook contained 5 simple examples, clearly sub-sectioned and each example represents a simple "freshman" Newtonian Physics problem, expressed in "vector calculus", should you find the time to explore this issue.

I heard back from Wolfram Tech Support and sadly, they could not resolve these issues with Quantity and related functions. The "Units.nb" is from Wolfram Tech Support. See attached. It does not improve on the issue and seems to confirm my complaint that Mathematica is "broken" or "limited" in this regard. Seems like a huge step backward.

Regarding a working copy of V4, no, unfortunately my laptop with a working copy of V4 died decades ago. I do have the original V4 code and the original V4 output. 100k plus lines of code that worked fine in V4 but fails miserably in V12.

The sad thing is, what was a piece of cake and pleasure in V4 is now a pain in the backside, made worse by the fact that there is no way to avoid these issues with Quantity except perform complete "unit-less" calculations.

Should there not be a "global switch" that tells the kernel to ignore anything related to Quantity, and permit "home rolled" V4 style units?

Just a thought!

Hard to say with an image instead of the actual code, but it looks like you redefined a to be a vector comprised of two scalar components, because the subscripted elements Subscript[a,x] and Subscript[a,y] are not themselves quantities with associated units. So that would lead to a quantity incompatibility.

On a different note, you did provide a notebook showing problematic computations. But it is huge and has nothing remotely resembling a minimal example of the shortcoming(s). It is simply not something I would be prepared to wade through. I'll take a look at the example provided by @Neil Singer when time permits.

As I believe the code and discussions have easily shown, Mathematica V12 and the unavoidable forced incorporation of the Quantity function has "broken" Mathematica in an important way. THIS IS A BUG!

From what I can determine, there is NO WAY to get Mathematica V12 to work flawlessly with Units from the built-in Quantity function. The best results I have been able to obtain have correct numerical values but Units are lost by functions such as Solve and NSolve. This would seem to be a MAJOR BUG in V12.

Also, curiously, for a guy like me who as been out of the Wolfram universe for decades, no one on sites like this one, or StackExchange, or even Wolfram Tech Support know the answer.

Instead, the experts in the field all (1) avoid using units and Quantity at all cost, or (2) add 1000's of lines of "rewrite rules" to clean up the faulty V12 output, or (3) try unpredictable overloading of the Quantity function in a last act of desperation.

No one I have discussed this with seem to know how to use Quantity and obtain valid results.

Lastly, no where in the Wolfram docs can I find anything but the most trivial example of Units and Quantity. In simple cases it can work. In more complex cases, from my money, Quantity simply does not work.

With the addition of the Quantity functions and all the modifications to prevously existing functions, like Plus or Integrate or Solve or NSolve, (all new or "updated" in V9, I believe), Mathematica now limps down the road like a car with a flat tire.

Very sad ;-)

This is not a bug. Ay is actually unitless. When you define a value as Quantity[Ay, "Unit"]. Ay is a scalar BUT the whole expression is a Quantity with units. If you solve for Ay, its always scalar. If on the other hand, you define Ay = Quantity[AyScalar,"Unit"] then Ay is a Quantity object with units and if you solve for Ay, it will have the right units.

I your example, this will work in your notebook:

Subscript[
\!\(\*OverscriptBox[\(a\), \(\[RightVector]\)]\), 
  1] = {ax, Quantity[0, ("Meters")/("Seconds")^2]};
Subscript[
\!\(\*OverscriptBox[\(a\), \(\[RightVector]\)]\), 
  2] = {Quantity[0, ("Meters")/("Seconds")^2], -ax};

Using the notation package and symbolizing expressions is generally fine but can have pattern matching issues if that is not taken into account in other code. I would suggest trying some simple examples with and without symbolized notation to see if that is the source of the problem. I could imagine (with no evidence whatsoever) that the Solve pattern matching with units could have a bug in treating those symbols. If so, tech support is very responsive and it might get it fixed fairly quickly if you can isolate the behavior.

I find that a smoother way to handle units is to avoid putting them into expressions at the beginning of a calculation but only put them in at the last steps.

Write a set of rules that give the numerical and unit values for each of your variables. Then do your algebraic calculations symbolically, using these rules at the conclusion.

I've written an application called UnitsHelper that helps with these problems, If you write to me I can send you a Dropbox link.

One of the routines, Deunitize, will remove the units from an expression in such a way to have implied input units and an implied output unit (and checks for consistency.).

UnitsHelper also has provision for defining reduced unit systems such as geometrical units or atomic units, general decibel units, and handy palettes.