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"]

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

Thanks for the simplifications. This example, while still a bit on the long side, removes several extraneous features and overall is vastly more clear than others I have seen. It helps me to put into words some thoughts that have been in the back of my mind.

First of course is that Solve, well, solves. For something.or some things. It makes sense that it might solve for units as well as magnitudes. Integrate in contrast has to handle units in a different way. One of its tasks is to impute correct output units from given input units.It does not, and should not, take into account an "external" environment wherein its use in a larger expression confers unit behavior on its variables or parameters. In your use case, the Integrate result is a summand, and another summand has units that are incompatible with it.

You claim that this is a severe flaw. I will maintain that, quite the contrary, it is an important strength. It allows for detection of units mismatches, which in turn enables the basics of dimensional analysis. Moreover it means there is no hidden "read my mind" behavior wherein units are assumed and nowhere made explicit (Solve, in contrast, shows the units it has deduced). Yet another reason to not go down this road is that there would be no way to prevent different assumed units to be ascribed to the same variable when used, say, in separate integrals.

I really think that what you are expecting, if you consider it carefully, would be not just difficult to deliver but also both fragile (in implementation and potential usage) and outright dangerous in terms of resulting behavior. It would provide no protection against dimensional mismatches in a sum, for example. It would require assumptions that are nowhere made clear. And it would be unable to protect against mismatches involving different unit assumptions being placed on the same variable when used in different places.

This is going in circles.

I have just looked at the notebooks and all the images in the posts above. Other than an example from Neil Singer, I have not seen anything that strikes me as amiss. I have seen reams of confusing code, possibly (likely, in my view) containing some degree of user error. Often in that situation code will not perform as the author expects. In such cases it is best to isolate a small number of clear examples that show the pathology. Should you do so, please post them and I'll have a look.

Earlier today I was shown a small set of examples from our Technical Services group. It may have originated with you. It contained among other things, this Integrate.

Integrate[v, Quantity[3,"Seconds"]]

I am not able to make sense of this. I will look later when time permits, but my current thinking is that it is a case of garbage-in, garbage-out that Integrate simply fails to catch. The best documentation I could find is in the Documentation Center under tutorial/SymbolicCalculationsWithUnits. It indicated that an appropriate method for obtaining what I believe is the desired integration would be this.

In[433]:= InputForm[
 iiDef = Integrate[v, {t, Quantity[0, "Seconds"], Quantity[3, "Seconds"]}]]

Out[433]//InputForm=v*Quantity[3, "Seconds"]

This can be used inside Solve without causing confusion as to units.

As a general remark, it is considered bad etiquette to claim there is a bug before it has been confirmed as such by others (whether Wolfram employees or not). Insisting these examples show serious bugs is the sort of thing that would get a question closed on Mathematica.StackExchange.com, and sometimes on Wolfram Community as well. Again, if you have a clear example of a bug, show it. It is not reasonable to expect others to go over reams of code trying to figure out what you mean.

Francis,

I believe your problem is the subscripts and not the units. Solve handles the units properly as long as there are no subscripts in the variables. I have noticed that Solve never handles subscripts well even without units and I have gotten strange results over the years using subscripts. I would use f1 instead of Subscript[f,1] etc.

I hope this helps,

Regards,

Neil

Hans, thanks for your time and input.

Yes, that approach occurred to me, and was why I suggested to Daniel that the y-component of aVec should be (perhaps) "0 m/s^2", even though it makes no sense from a classic definition of differentiation in Calculus.

Here we notice that the "units" get altered the first time in y-component, but not a second time:

vVec = D[rVec, Quantity[t, "Seconds"]]

Which outputs:

{(Quantity[1, 1/(
    "Seconds")]) (t^2 (Quantity[-0.6, ("Meters")/("Seconds")^3]) + 
    t (Quantity[2.4, ("Meters")/("Seconds")^2])), 
 Quantity[0, 1/("Seconds")]}

And:

aVec = D[vVec, Quantity[t, "Seconds"]]

Which produces the same units in the y-component and hence, does not work:

{(Quantity[1, 1/(
    "Seconds")^2]) (t (Quantity[-1.2, ("Meters")/("Seconds")^3]) + 
    Quantity[2.4, ("Meters")/("Seconds")^2]), 
 Quantity[0, 1/("Seconds")]}

I basically agree with Daniel that the derivative of "0 m" should just be "0".

But that does not fix the problem or permit complete, cogent results in V12.

Something is terribly wrong with the Quantity function!

Regards, - Joe

I'll discuss the part about taking derivative with respect to t of your rVec. You claim:

"The "units" for the y-component of rVec have been deleted by the Derivative function.

And although zero oranges fills one's hand in the exact same way as zero apples, the y-component of aVec would seem to need to be in units of m/s^2. But as we can see, now after taking the derivative of rVec all units for the y-components of vVec and aVec have disappeared."

My responses, in order, are yes, nonsense, and agreed. Yes, the units components are gone in those derivatives (thus agreed, they have disappeared). The fact that the Quantity had a magnitude of zero is irrelevant (and this should have been tested). The part about "would seem to need units of m/s^2"?? Where on earth did that come from? Why seconds^2? You have taken a derivative of something that is constant with respect to the variable of differentiation. That variable itself has no assigned units. Thus there is no conceivable unit to be assigned to the derivative.

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

Out[758]= 0

If you want a quantity result, you need to give input from which units can plausibly be imputed. Like this next, for example.

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

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

I have not checked claims below this part. I am assuming that further behavior falls out from the misuse/misunderstanding of units I am indicating here.

I (and colleagues) are expending real time trying to discern what might be actual bugs or weak points, from what are just misuses. We have found and fixed one (obscure) bug. We also now have an open suggestion report for Solve. But we are hitting diminishing returns insofar as most examples you show, and rail about, are neither bugs nor bad design decisions, but simply things that are not carefully analyzed. No, this is not version 4. Version 4 had no concept of units. This is version 12, and it has years of units development. Forcing consistency? Yes, it does that. A units system is hopeless if it fails to do that. Weak spots in inferencing? Yes, I think you may have shown one, most likely in Solve. We'll take that into consideration.

Wow, I bet your code was running on the simulators in Fort Worth.

I will never forget watching the Airforce brass show up informally on weekends, dive into a couple, interlinked, full cockpit, 360 degree simulators and dogfight away on a Saturday afternoon. In the days of "Pong" this represented the best, multi-million dollar video game on the planet!

FYI, this post is just my opinion on V12 architecture. No code or solutions.

David, thanks. I appreciate the feed back and suggestions. I agree, as I said to an earlier post of yours, that such re-write rules are possible, and it appears now, the ONLY FIX.

The thing that makes me weep is when one considers how much more coding baggage it takes to produce coherent results in V12, than in V4. What you are proposing is pages of extra code, that obfuscates the simple, vector calculus defining a basic exercise in Newtonian Mechanics, that at a glance, by anyone with calculus/physics in their background, not only explains the "physics problem" in one "cell's worth" of V4 code, but also it's complete solution.

Coding in V4 was like mathematical poetry.

Short, sweet, moving, to the point.....

V12?

Not so much ;-)

My contention now is that V12 seems to enforce this unit based "type-checking" too rigorously or too early.

In fact, your code above perfectly defines the approach I am suggesting be hard-coded into kernel implementation of Solve, Plus, Integrate, etc...

That is, as a basic default behavior of Solve/NSolve/Integrate/Plus, etc... in V12 should be implemented in such a way as to "keep the units" correct!

Solve/NSolve, etc... should, by default I believe, ALWAYS return correct magnitudes and correct units, whether such units explicitly defined (via Quantity), or implicitly defined in a unit-less fashion by the central mathematical relationships in the equations being solved. That is my contention (not one widely shared apparently) and I am sticking to it ;-)

Just think of the power this would give to a college student, for example, who is trying to deal with a problem in Newtonian Mechanics, and not a problem about programming language syntax errors.

Just imagine, like the great V4 days, if a student could basically type in, easily, in very few keystrokes, the exact mathematical language shown in his/her textbook on physics or calculus and evaluate it. The first time I realized this was the V4 default behavior, I fell out of my chair. I thought such Mathematica behavior was beyond cool!

Like them, I use Mathematica as the world's great "note taking sytem". With it, one can study, explore and take notes so detailed, and perfectly typeset, that the answers just fall off the digital notebook page. To me, Mathematica is a microscope, a telescope, a tool that makes the invisible, visible!

Like them, I am looking for a tool, like V4 surely was, that I can use to explore subjects like Calculus, Physics, Linear Algebra, Logistic Equations, Combinatorics, etc....

But sadly, I have 100s of 1000's of lines of code, that I wrote in V4, exploring the disciplines above, that would never, ever evaluate correctly in V12. For me, that lack of backward compatibility, is a huge personal loss. Years of hard work, now "read only". I selected V4 initially for such adventures in the 1990's because I was confident my efforts, like some old piece of Cobol, would execute everywhere, anywhere and at anytime in the future. Apparently not.

That said, all complaining aside, there is no real competition for the Mathematica and the Wolfram Language.

Mathematica is a superb engineering feat. For my money, no Jupyter fronted whatever, could ever hold a candle to Mathematica. Some of the stuff that has been added post V4 are astounding, like DynamicModules. Wow!

But, my work in V4 was just a retired engineer's "fly fishing adventure", minus the Zika and the Dengue. I enjoy Mathematica the same way I enjoy skimming the tree tops in Cessna 182 on floats, and popping down onto clear Maine lakes or the way I use my '57 ES-175 when transcribing Joe Pass chord-solos... for the sheer, unrivaled buzz of it!

The first time I saw Mathematica was in the late 1980's, at General Dynamics, where I helped program the four parallel, flight control computers of the F16 A/B in Jovial. Mathematica V1 and it was running an original Apple Lisa, if memory serves. I was dazzled then. I still am!

I will always keep a licensed copy of Mathematica on my machine, as I have done for three decades. I am a dye-hard fan!

I just won't be able to "fly it" like I could in V4 apparently.

It is now a different vehicle ;-)

Thanks for everyone's help.

The last example, has no simple syntactical solution that produces both correct magnitudes and correct units for the output of Solve, at least none I have found after weeks of searching. There are some great YOUTUBE vids by Wolfram guys talking about the features of Quantity, but the bulk of those are about simple unit conversions and large currated libraries of mathematical constants, etc...

I have yet to find a single YOUTUBE or webpage, anywhere, where this sort of basic physics problem, is handled in the most compact vector calculus, and where Solve/NSolve return all explicit and implicit defined units for all variables.

Regards, - Joe

My apologies. I regret that you could not see the issue I am describing. I admit it only appears when trying to solve systems of vector calculus equations that incorporate Solve/NSolve, Integrate and Quantity.

Happily however, Wolfram Tech Support see it clearly and have forwarded the issue on the developers at Wolfram.

====================================================================== Re: [CASE:4734844] Quantity and Solve/NSolve not working correctly in Mathematica V12 Hello Joe,

Thank you for your email. I looked into this further and the source of the issue is that integrate is assuming a to be unitless. I have reported this to the developers and thank you for your feedback.

In the meanwhile, a simple workaround is to explicitly specify the units in the integration. In such a case, the output of Solve[] will be numeric, and then you can use the replacement rules to get the final answer as a quantity. Please see the attached notebook for details.

Best regards, Wolfram Technical Support Wolfram Research Inc. https://support.wolfram.com

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.

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};

It is my experience subscripts DO NOT work correctly in variable names UNLESS "Symbolized". See the attached notebook to see how this is done. You will note that my subscripted symbols are all interpreted correcly (because I used Symbolize). They cause no errors in my example notebook. It is only the UNITS that get screwed up by Solve and NSolve

Attachments:

Examples of Prob...nb

Thanks David. I have used this kind of late stage rewrite rules, to clean up output.

But I was hoping to avoid such an approach as it defeats the purpose of having units in a calculation in the first place. Ie., Units are like "strong typing" in a programming language, in the sense that it helps flag errors in calculations. If the units are "wrong" in the output of a calculation, that is a good clue that the whole calculation is somehow flawed, no? That is my main reason for wanting to use units in the first place. In V4, I could happily define my own, and things worked perfectly (see JPEGS of V4 syntax below). In V12, Quantity and the way Solve/NSolve check for unit consistency means no "home rolled" solution will work. Makes me think Quantity should be a "Package" and not part of the kernel.

My hope was Mathematica could do this correctly, and maybe it does and I have just yet to figure out how.

Should not a "units" feature in Mathematica be both working and central to it's function? As bullet proof as the Plus or Times function?

Wolfram apparently added this Quantity head somewhere around V9, 10 years later, and from what I can tell, it is still not working correctly. But, I will admit, I have not used Mathematica since V4, so I am no expert.

I have even looked from some "global switch", to tell all the functions like Solve to ignore all Quantity heads. But, sadly, I have not found one. The "Quantity" bag is firmly glued on to the side of V12. It just does not appear to work correctly. (or I am still missing a key idea).