Message Boards Message Boards

GROUPS:

Solve and NSolve not working well with Quantity and Units?

Posted 4 months ago
2303 Views
|
44 Replies
|
12 Total Likes
|

I am trying to update 100k lines of Mathematica I wrote 15-20 years ago in Version 4. I am struggling with getting Quantity, Solve/NSolve and Integrate to correctly deal with units. Solve/NSolve always return the correct numerical values, but the "Units" are quite often lost. I can not figure out why. But it seems related to the Integrate function and places where variable definitions first appear in the code as arguments to the Quantity function. The Plus function may also be failing. Also of note, is how "unit-less" variable name definitions seem the direct cause of the errors produced by the Integrate function. And perhaps at the root of my programming dilemma is the way multiplying a scalar Quantity by zero wrongly preserves Units.

In V4:

   200 kg times 0 equals 0

In V12

   200 kg times 0 equals 0 kg

This bug/feature, breaks simple vector calculus computations in countless ways. See the detailed examples given far below in this thread, where V12's forcing of units on values of zero magnitude causes simple exercises in Newtonian Mechanics to "blow up".

Any help would be appreciated. See attached notebook for examples of this behavior. JPEG attached for easy demonstration of typesetting. Code is in the attached notebook.

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

Solve not returning Units

NSolve working almost correctly

44 Replies

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.

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).

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

Thanks. Yes, ordinarily that might be a problem. But you can see that Solve and NSolve DO NOT get confused about my construction of variable names.

See the output from my attached JPEG examples in this discussion.

The variables "names", complete with Subscripts and Overbars, are all interpreted correctly, as the output from Solve and NSolve and the correct numerical values demonstrate. Only the Units get lost.

FYI, to get this rather LaTex looking typesetting (one of Mathematica's coolest features for my money) I use "Symbolize" from the Notation Package.

There are no examples where such variables written in this lovely sort of typesetting are misidentified by Mathematica. This feature of Mathematica has worked correctly since V1.

See below. Sorry for the JPEG, simply an easy way to show the correct typesetting. I have updated the attached notebook to include this code.

Code for Symbolize

Attachments:

I just did a quick test and the Subscript with units threw an error. The main variable and the subscript can both have units so I am not surprised that Mathematica gets confused.

This works:

In[10]:= R = Quantity[f1, "Newtons"];
m = Quantity[12, "Kilograms"];
Solve[R == m*a, a]


Out[12]= {{a -> f1 (Quantity[1/12, ("Meters")/("Seconds")^2])}}

This does not:

In[13]:= R = Quantity[Subscript[f, 1], "Newtons"];
m = Quantity[12, "Kilograms"];
Solve[R == m*a, a]


During evaluation of In[13]:= Solve::units: Solve was unable to determine the units of quantities that appear in the input.

Out[15]= Solve[
 Quantity[Subscript[f, 1], "Newtons"] == 
  a (Quantity[12, "Kilograms"]), a]

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:

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.

Thanks Neil. I understand the suspicion of the Notation package and Symbolize, but I have been using this package since V4, twenty years ago, and never had a problem with it.

That said, I think I have spotted a pattern. I will update the example notebook I attached to this discuss with the following example. Again, sorry for the JPEG. It is used to show typesetting. Code is in the notebook.

The pattern I have noted is that if a "variable" first appears as an argument to Quantity, then the Unit will never be correctly deduced by Solve or NSolve. Instead, the unit for such a variable will be lost. However, other variables, like my "force 2" variable in the JPEG below, that scalar too is never defined as a specific Quantity unit. But, Solve and NSolve correctly "deduce" the unit. I have examined a few dozen examples in my code, and the variable whose unit can not be deduced always appears as an argument to Quantity.

Is this a flaw in Quantity or am I misusing this function somehow?

Example

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

Thanks Neil. Yes, only variables assigned the output of a Quantity function have the quantity head. And you are also correct that redefining some variables can make this work (quite often). But the approach only works in simple cases. And F2, in the example above, is never assigned a Quantity head, and yet, Solve and NSolve can correctly deduce the units. Why?

For example, here are two cases where the change you suggested produces the correct output from Solve.

Example of working definitions

Also, this works:

enter image description here

However, this syntactical approach seems to still fail in the following example. For example, my original approach works (except for units output by Solve).

enter image description here

But if we attempt the same sort of thing you are suggesting here, then the total lack of Quantity definitions causes the simple functions like Integrate and Plus to "choke".

So, for this kind of calculation I am still at a loss for the correct approach.

enter image description here

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

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? ;-)

enter image description here

enter image description here

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.

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!

You forgot to attache the Units.nb file. However, doesn't what I last posted solve your problem for both integration and Solve?

Regards,

Neil

Hi Neil, No I did attach the Wolfram Tech Support notebook called Units. It can be found in the first attachment section of this discussion. Start at the top and scroll down. In the notebook, you can see that Wolfram Tech Support was unable to produce the correct units via Solve and NSolve. You will also not how ridiculously easy such a task was in V4. See JPEGS above! How I miss V4 ;-) Regards, - Joe

Do you still have Version 4 on your computer? If so you might be able to use the old MiscellaneousUnits and MiscellaneousPhysicalConstants. I thought I had saved a copy of them at the time WRI switched over but I can't find them now. I do have an extension Units2` done by Ted Ersek that substitutes for the old Units but it still requires PhysicalConstants.

The old system also allowed one to install their own units, which I don't think can be done now.

Maybe you could get those packages from Wolfram.

I don't think there are any real benefits from dragging Units through all the algebraic routines. It doesn't guarantee that the units are correct because it's possibly to use wrong units consistently. If Mathematica is going to let you use units everywhere then you are right that it should be better implemented.

No, David. I do not have a working copy of V4. Sure wish I did ;-) I know the Units package to which you refer. Many such packages are no longer "optional" and are now just built into the kernel, like it or not. The package architecture was a good one I believe. I wish Quantity was in some package, that I could delete from my laptop and return to beautiful V4 functionality. ;-) Pero, por desgracia, V4 es un idioma muerto ;-) Tenga buen dia, - Joe

The problem is that you are mixing scalar and unit variables. In your example, ax is a scalar but you are integrating over a Quantity[]. For example, something like this works:

bbx :=  Quantity[bxscalar, "Meters"/"Seconds"^2];
bby :=  Quantity[byscalar, "Meters"/"Seconds"^2];

bvector = {bbx, bby};
Solve[bbx ==  
  Quantity[33, "Meters"/"Seconds"]/Quantity[12, "Seconds"] , bbx]

Out[215]= {{Quantity[bxscalar, ("Meters")/("Seconds")^2] -> 
   Quantity[11/4, ("Meters")/("Seconds")^2]}}

In[216]:= Subscript[
\!\(\*OverscriptBox[\(v\), \(\[RightVector]\)]\), 0] + 
 Integrate[bvector, Quantity[t, "Seconds"]]

Out[216]= {Quantity[(2.8  + bxscalar t), ("Meters")/("Seconds")], 
 Quantity[(0.  + byscalar t), ("Meters")/("Seconds")]}

You can probably make a wrapper function to make this easier -- I'll think about it a bit.

Regards,

Neil

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).

Part 1 Part 2 Part 3 Part 4

Attachments:

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.

Working example

The integral that I see from several messages back appears to work just fine. The message arose from an attempt to add quantities of nonconforming units.

You are making this quite difficult to even follow, let alone diagnose. I will suggest that you provide full code in the post, avoiding Subscript unless that is absolutely needed to reproduce the problematic behavior. It should be copy-pastable. I for one am not going to rekey from images because that is both laborious and error-prone.

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.

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.

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

Francis,

I think there is a big misunderstanding. I also do not see a bug here -- I think it is a misunderstanding of what Quantity does and how it is supposed to work. Please let me try to explain:

This expression:

Quantity[t,"Seconds"] 

DOES NOT declare t as a variable with units of seconds. t ramains a scalar number without units. If I define

vart = Quantity[t,"Seconds"] 

In this case, "vart" DOES have units of Seconds (but "t" is still scalar). You MUST use vart everywhere you want a variable with units (in the Solve and in the Integrate. Here is some sample code with the subscripts removed to make it clear.

bbx :=  Quantity[bxscalar, "Meters"/"Seconds"^2];
bby :=  Quantity[byscalar, "Meters"/"Seconds"^2];

bvector = {bbx, bby};
Solve[bbx ==  
    Quantity[33, "Meters"/"Seconds"]/Quantity[12, "Seconds"] , bbx]

 Integrate[bvector, Quantity[t, "Seconds"]]

Both these examples work and are consistent do I don't understand the problem. Can you point out what I am missing with my simple example above? Maybe then, Daniel or I could be more helpful.

Regards

Neil

Neil,

I am sorry I have been unable to make this issue clear. It is a subtle point, made more confusing by my rather ornate use of variable names.

So, as requested, I will try here to illustrate it with code that is more easy to copy. I hope that helps. I will, as always, attach a notebook for convenience.

For comparison, here is a simple example where Solve, quite properly I believe, deduces the correct units. Notice in this first example the vector aVec is defined in a unit-less fashion. None the less, Solve will still correctly determine the units from the calculation.

m = Quantity[40, "Kilograms"];
g = Quantity[9.8, ("Meters")/("Seconds")^2];
aVec = {ax, ay};
Fw = m*g;
FwVec = AngleVector[{Fw,  270 Degree}];                                         
F1Vec = AngleVector[{Quantity[20, "Newtons"], 0 Degree}];  
FnVec = AngleVector[{Fw, 90 Degree}];                                            
RVec = F1Vec + FnVec +  FwVec;                                                          
Solve[RVec == m*aVec, aVec]

This produces the following output:

{ax -> Quantity[0.5, ("Meters")/("Seconds")^2], 
 ay -> Quantity[0., ("Meters")/("Seconds")^2]}

So far so good. Notice that although aVec in the simple example above was defined without units, Solve could determine the units from the calculation and the lack of units is not a show-stopper. This seems to me to be reasonable and correct Mathematica behavior.

Now consider a similar calculation that requires the Integrate function.

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;                                   

In this example, the lack of units for the aVec appears to be a complete showstopper for Integrate. The following will produce many Quantity related errors.

v0Vec + Integrate[aVec, Quantity[t, "Seconds"]]

So, executing the following line, which is a valid mathematical description of the solution, will never work in V12, for the reasons outlined.

 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}] // First 

It seems to me that it most definitely should work in V12, like it so beautifully did in V4. But it does not. The lack of units in the definition of the aVec vector seems to cause a whole class of solution expressions, that are perfectly valid mathematically, to no longer be calculable in Mathematica V12. How could such a fault be anything less than a "flaw" or "bug" or "mistake" in the architecture of units in V12 via the Quantity function?

So, in conclusion, here is why this strikes me as a "flaw" in V12.

Because in V4 (see example in attached notebook or JPEG below) these sort of unit-less variables did not stop the Integrate function from completing it's task. In V4, before the Quantity function was introduced and before functions like Plus, Integrate, etc... were re-coded/updated, the units for aVec were easily deduced from the calculation itself. Is this not superior? This is how it worked in V4. I found such functionality both beautiful and effective. But I can not find a way to make V12 behave in this V4 superior manner, and deduce the units of variables not explicitly defined with Quantity. Part 1

It feels like I am saying the same thing, over and over.

Does this make any sense? Regards, - 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.

Thanks Daniel.

I agree completely with your observation that the Summand and units are the problem with Integrate. I mentioned previously my suspicion that changes to Integrate and Plus functions, among others, to tightly couple this Quantity based units architecture was at the root of my difficulties. Clearly we can multiply two variables of different units. Newtons times Meters equals Joules. But "adding" two variables with different units, that of course is problematic. I would contend that the only reason the first Solve example works is because it is Newton's Second Law, and expressed as mass "times" acceleration.

Look, I am the blind man describing the elephant. I have no firsthand knowledge of how Integrate, Plus, Quantity, Solve, etc... are actually implemented in the kernel, but it seems to me that there is a critical flaw in the architecture of Units in V12. That said, I also agree with you, that this would probably be very difficult to fix now, since this architecture has been so uncompromisingly coupled to V12.

But as a hunch, it seems like V12 and this units architecture is too "strict" or "too strongly typed" in a sense. I wonder if Integrate or Plus could be made to delay this sort of unit "type checking" when passed as an argument to Solve/NSolve such that the units can be correctly deduced. The math I am trying to represent in Mathematica could be solved by any high school student on a chalkboard, and said student would certainly produce both the correct magnitudes as well as correct units, even for vectors like aVec above that are defined in a unit-less fashion. No? So is it unreasonable to expect Mathematica to be as powerful?

Hence, you must agree that what I desire here from V12, and what was easily doable in V4, is now impossible in V12.

Is that a fair statement?

I think you will also agree that the ability to leave variables unit-less and have the units deduced by the calculation itself is "Algebra 101".

And since no one has yet to show me how to define the variables "ax" and "ay" (in the aVec example above... that requires the use of the Integrate function) such that, it works in the sense I have been describing.... I am thus forced to conclude, that what I loved about V4 is, thanks to the Quantity architecture in V12, now impossible. Do I have that right?

I have to tell you, as a guy with considerable V4 experience, I would happily trade "free form input", "entities", "wolframalpha", "auto-completion" ,etc... for this basic functionality in V4 to elegantly define and solve simple mathematical expression in the fashion I have described.

That said, I can now see, I am beating a dead horse, or at least "un idioma muerto, version 4".

Thanks for your time on this. Sorry drag this out. I thought someone would quickly see how I was trying to have the calculation deduce the units, like in V4, and say "oh... to do that you need do this...." But alas, it's seems that what I loved most about Mathematica is now impossible.

Know where I can buy a copy of V4? ;-)

Like Huey Lewis, I need a new drug! ;-)

Regards, - Joe

I am lapsing into the category of rendering opinions rather than explaining functionality, and I do not intend to pursue this very far. I'll just try to address the concerns raised above, give a bit of background (which is actually not opinion), and leave it at that.

First, it is different to solve for, and then use, units, vs. imputing them from surrounding context. In your examples, a slightly different formulation would allow you to determine, e.g. with Solve, appropriate units for your integrand or variable of integration. While your proposed HS student might well figure out the units necessary for a computation to "make sense", ask yourself what this would entail in the context of a programming language. Chances are you will determine that there should be an explicit dimension solver, and that there should not be assumptions made that are not clearly carried through elsewhere in the computations. By this I mean it should not silently be assumed in one place that variable a has units of meters/seconds^2. This would be a dangerous road to take since (i) the user would not be told (maybe the user thought a was apples/bananas^2) and (ii) perhaps a different line of code would do similar but now require that a be elephants/rhinos^2. You would have a very well hidden incompatibility. This is not how Mathematica is designed to behave!

Next, while I was not involved in the design of the units system that went into recent versions, I certainly endorse the present behavior of not allowing Plus to add apples to oranges. What you propose as better, at heart, would silently reconstrue the oranges as apples.

This brings me to an important point, which, granted, is a matter of opinion. I do not agree that the design is wrong, or the system in need of fixing, at least with respect to the examples you have shown.

You raise questions about handling of units in version 4. I was heavily involved in development of Solve code for that version. I was also heavily involved in work on Integrate code at least as of version 4.2 development. Neither function had any code at all to work with units. Neither made any assumptions about units. Adding apples to oranges was fine, since both were dimensionless beasts. Scalars, if you will. If version 4 did something you like, well and good. But it was hardly a system that would work with units per se, let alone be capable of native deployment in a dimensional analysis setting (by "native" I mean by using internal units with dimensions; these did not exist inside Mathematica back then).

You ask whether what you wish to do is impossible in version 12. Here again we get into the slippery slope of opinion. Perhaps it is not possible, if you insist that it happen in very particular ways. My take is that it would be better to learn a bit about how units are handled in recent versions of Mathematica, and then to work within that framework. Certainly it is straightforward to do this using the Integrate and Solve examples I was shown by Tech Support yesterday. Is my proposal too much of a change in workflow to be comfortably negotiated? I cannot answer that of course. But it is the best thing I can advocate.

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

If I understand things correctly you say Solve cannot handle units, but:

Solve/NSolve always return the correct numerical values,

Well, is it possible that Solve evaluates expressions as far as possible and then it could occur that units are cancelled on both sides of an equation. Look at this with "unit" b

Solve[a g b == x b, g]

Francis, I think your work looks impressive and I know you have put a lot into it. It is one approach but I don't think it's the best approach even if Integrate would handle units. I think it's much better to keep symbols as symbols and be able to manipulate symbolic expressions and only insert the units at given points, usually the conclusion of the calculation. Here I try your two cases.

Case 1

Specify the input data:

data1 = {
   m -> Quantity[40, "Kilograms"],
   g -> Quantity[9.8, ("Meters")/("Seconds")^2],
   Fh -> Quantity[20, "Newtons"]}; 

This has the advantage that the symbols are not given values so we can use them in algebraic expressions and calculations.

Now we can carry out a symbolic derivation. Everything is a symbolic expression and it this case we don't even really have to use Solve.

gravityForce = m g AngleVector[{1, 270 Degree}];
normalForce = m g AngleVector[{1, 90 Degree}];
horizontalForce = Fh AngleVector[{1, 0 Degree}];
resultingForce = gravityForce + normalForce + horizontalForce
accelerations = {ax, ay} = resultingForce/m

giving

{Fh, 0}
{Fh/m, 0}

Now substitute the input data and convert to SIBase units.

accelerations /. data1
UnitConvert[%, "SIBase"]

giving

{1/2 N/kg,0}
{1/2 m/(s)^2,0}

Case 2

Input data

data2 = {
   m -> Quantity[0.45, "Kilograms"],
   g -> Quantity[9.8, ("Meters")/("Seconds")^2],
   Fh -> Quantity[20, "Newtons"],
   r0 -> {Quantity[0, "Meters"], Quantity[0, "Meters"]},
   r1 -> {Quantity[1, "Meters"], Quantity[0, "Meters"]},
   v0 -> Quantity[2.8, ("Meters")/("Seconds")],
   v1 -> Quantity[0, ("Meters")/("Seconds")]};

Initial conditions and vector forces:

v0Vec = v0 AngleVector[{1, 0 Degree}];
v1Vec = v1 AngleVector[{1, 0 Degree}];
FgVec = m g AngleVector[{1, 270 Degree}];
FhVec = Fh AngleVector[{1, 180 Degree}];
FnVec = m g AngleVector[{1, 90 Degree}];
RVec = FhVec + FnVec + FgVec
Clear[ax, ay]
accelerations = {ax, ay}

giving

{-Fh, 0}
{ax, ay}

Again we have symbolic expressions. We can write a set of rules for the accelerations.

accelerationRules = Thread[accelerations -> RVec/m]

giving

{ax -> -(Fh/m), ay -> 0}

Now we can evaluate your expression for the velocity. There is no problem.

v0Vec + Integrate[accelerations /. accelerationRules, t ]
% /. data2
% /. t -> Quantity[10, "Second"]

giving

{-((Fh t)/m) + v0, 0}
{t (-44.44444444 N/kg)+2.8` m/s,0}
{-441.644444444 m/s,0}

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

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...)

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!

Here I go again.

My knowledge of V4 is shooting me in the foot at every turn, as I attempt things that were so easy and elegant in V4 and now, despite my best efforts unobtainable (the same way) in V12.

Here is another, almost spooky example.

Consider the following setup for another simple problem in Newtonian Mechanics:

m = Quantity[200, "Kilograms"];
g = Quantity[9.8, ("Meters")/("Seconds")^2];
Fw = m*g;
F1Vec = AngleVector[{F1, 0 Degree}];
FwVec = AngleVector[{Fw, 270 Degree}];                                       
FnVec = AngleVector[{Fw, 90 Degree}];
RVec = F1Vec + FwVec + FnVec; 
UnitSimplify[{m, g, Fw, FwVec, F1, F1Vec, FnVec, RVec}] // N

Now add to this, a position vector that changes as a function of time

rVec = {Quantity[1.2, ("Meters")/("Seconds")^2] t^2 - 
   Quantity[0.2, ("Meters")/("Seconds")^3] t^3, Quantity[0, "Meters"]}

Now, this definition of the rVec seems reasonable, as it will return both correct magnitudes, as well as, correct units:

rVec /. t -> Quantity[3, "Seconds"]

Which correctly produces the following output:

{Quantity[5.4, "Meters"], Quantity[0, "Meters"]}

So far, so good.

Now, let's take a couple derivatives of rVec to obtain aVec:

vVec = D[rVec, t];
aVec = D[vVec, t];

Now we immediately see a major problem, if we compare rVec to aVec.

The "units" for the y-component of rVec have been deleted by the Derivative function, which makes mathematical sense, but causes problems later. The Derivative of "0 m" is and should be "0", without units. And this at least, is what happens.

And although zero oranges fills one's hand in the exact same way as zero apples, the y-component of aVec would almost seem to need to be in units of m/s^2, to create a "0 m/s^2" value in the second derivative of the position vector rVec. I realize that this makes only partial sense, but consider, Quantity[0, "Meters"] returns "0 m", which is also kind of meaningless. But as we can see, now after taking the derivative of rVec all units for the y-components of vVec and aVec have disappeared.

rVec
vVec
aVec

Which now equal, the following respectively:

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

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

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

Now, the first thing we notice is that there are no units for the y-component of vVec and aVec, which is mathematically correct, I believe. However, that lack of units in aVec will easily break Solve/NSolve as I will show in a moment.

The second odd thing is that the derivative of the x-components of vVec and aVec look correct. I note that when differentiating the x-component of rVec, the units never changed in the x-component, only the magnitude of the Quantities change, as does the variable "t". All correctly, I believe.

And of course, the goal was to use Newton's Second Law to determine the F1 scalar defined above.

But now, with no units in the y-component of aVec, when I multiply aVec times the scalar mass Quantity "m", I get a really squirrelly result:

m * aVec

Produces the following nonsense:

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

Which will of course make Solve/NSolve explode (and for good reason).

This approach, which worked so elegantly in V4 and is mathematically correct in it's basic design, is junk code in V12.

As always, any help or syntax corrections would be appreciated.

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.

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

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

Daniel,

Yes, I agree completely that the derivative of "zero anything" is "zero."

So, yes, the units should disappear from the y-component of the rVec when differentiated into vVec and aVec. That does indeed seem to be the calculus I was taught in school.

But there is still a behavior in V12 relative to Quantities and multiplication that I suspect lies at the root of this particular computational dilemma.

Here is a question for everyone:

Should "200 kg" times the number "0" be just "0" or "0 kg"?

In V4, the answer was "0".

In V12, the answer is "0 kg"

Quantity[200, "Kilograms"] * 0

Which outputs as:

Quantity[0, "Kilograms"]

This idea, that in V12 quantities with magnitude of zero can still have "units" is what breaks the following calculation:

m * aVec

Because this produces, an essentially meaningless result.

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

Which makes using Newtons Second Law impossible in this "vector calculus" based definition of the problem and solution to a simple exercise in Newtonian Mechanics.

It is stuff like this, I believe, that makes all basic suggestions I have received on the Quantity issue, things like like:

"avoid this Quantity feature in V12 and all cost. Best results are obtained with unit-less calculations and re-write rules to clean up the incomplete V12 output."

In the Wolfram video below, they demonstrate that "dollars" are the most requested unit in V12.

I wonder what function name is most often searched for in the Wolfram docs? Could it be "Quantity"? ;-)

Good Wolfram Talk on Quantity, as far as it goes

I would still trade my V12 for V4 in a microsecond!

Please, if you know of any similar talks, like the Wolfram lecture above, that addresses my concerns and might show me how to perform basic "vector calculus" with V12 units, please post a link.

Thanks, - Joe

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.

Mathematica is NOT a programming language

Then someone should send this observation to Stephen Wolfram, cause I guess he is still confused ;-)

Wolfram Language

I rather incorrectly use the phrases Mathematica and Wolfram Language interchangeably. I do understand the language has a "front end", if that was your point.

I also agree with you, that "units" get more cumbersome as the complexity of the calculations increase, and in many "real world" cases, units are more hassle than they are worth. Just add them back later, if need be, with a substitution rule. But, for my money, one can not really understand concepts like "heat", "work", or "energy" without understanding the "units". The basic ingredients of physics are defined by their units. So this is why classic books on college physics, like University Physics (where many of my examples come from) always shows "units" in the calculation, at least the first time a new subject area is broached.

I am no physicist, but when I used to rub shoulders with a few, as they stood before white boards in hallways at the Superconducting Super Collider, brainstorming control system designs for magnets, that took the effects of relativistic physics into consideration, I seem to recall "units" on the whiteboards, at least a few ;-)

SSC

BTW, David, I NOT was referring to your code specifically as baggage. I was referring to mine own. Or more abstractly, the case where getting the right output from V12 requires code that it simply should not require. That was my point. In my judgement (just a lone opinion) the Quantity function is a nightmare. As clearly seen from the way multiplying a "vector" (like aVec above), which may have components equal to zero (from differentiation, for example), by a scalar Quantity, causes V12, with it's "less than thought out" and "less than thoroughly tested" Quantity system, to produce mathematical junk as output. Did Stephen Wolfram sign off on this?

200 kg times 0 equals 0, not "0 kg". This forcing of units onto quantities of zero magnitude breaks Solve, Integrate, Plus, etc.. in V12 in dozens of examples, of which I have listed a few.

Be well, stay safe, - Joe

I have posted a new thread summarizing issues with Quantity that have been raised here. Further responses should go to that thread. This one has a considerable noise-to-signal fraction and we need to close it. We ask that responses in the new thread be kept to the point. The issues in question involve handling of units. I remark that version 4 had no built-in handling of units. Comparisons to version 4 are thus not regarded as on point.

Group Abstract Group Abstract