# Recently reported issues with Quantity

Posted 11 months ago
2712 Views
|
3 Replies
|
5 Total Likes
|
 I will attempt to summarize the salient issues that have been raised in this Community thread. We thank the original poster, and several who have responded, for helping to bring these to light. But the thread has been diffuse, has rambled, and has some aspects of "rant" posts (unintended, I realize), and we do need to draw it to a close so the actual issues do not get lost in noise. Further discussion should proceed in this new thread. If there are issues I have missed, they can be raised here. Note however the caveat that responses should be concise and not stray from current handling of units via Quantity.(1) Due in part to a transcription error, we learned that this evaluates. In[786]:= Integrate[v, Quantity[3, "Seconds"]] (* Out[786]= Quantity[3 v, "Seconds"] *) This should not evaluate but rather issue an error message. It has been fixed for a future release.(2) Here is the integral that had been intended. In[787]:= ii = Integrate[v, Quantity[t, "Seconds"]] (* Out[787]= Quantity[t v, "Seconds"] *) It looks fine. But there is a subtlety one sees in the InputForm. In[788]:= InputForm[ii] (* Out[788]//InputForm= Quantity[t*v, "Seconds"] *) In contrast, a straightforward multiplication will not pull v inside the Quantity. In[790]:= ii2 = v*Quantity[t, "Seconds"]; InputForm[ii2] (* Out[791]//InputForm= v*Quantity[t, "Seconds"] *) This matters, for purposes indicated in the prior thread, because Solve handles one form but not the other. In[792]:= Solve[ii2 == Quantity[3, "Meters"], v] (* Out[792]= {{v -> Quantity[3, ("Meters")/("Seconds")]/t}} *) In[793]:= Solve[ii == Quantity[3, "Meters"], v] (* During evaluation of In[793]:= Solve::units: Solve was unable to determine the units of quantities that appear in the input. Out[793]= Solve[Quantity[t v, "Seconds"] == Quantity[3, "Meters"], v] *) We acknowledge that this is a weak spot and it is currently under discussion. That stated, there are some tricky underlying issues and I cannot guarantee there will be a "good" resolution.(3) One post gave rise to a simple example showing another weak spot in the unit inferencing. First example works fine, second one fails. The only difference is that in one the scalar magnitude is a symbol while in the other it is an expression with a head. In[798]:= rr = Quantity[f, "Newtons"]; m = Quantity[12, "Kilograms"]; Solve[rr == m*a, a] (* Out[800]= {{a -> f (Quantity[1/12, ("Meters")/("Seconds")^2])}} *) In[801]:= rr = Quantity[f[1], "Newtons"]; Solve[rr == m*a, a] (* During evaluation of In[801]:= Solve::units: Solve was unable to determine the units of quantities that appear in the input. Out[803]= Solve[Quantity[f[1], "Newtons"] == a (Quantity[12, "Kilograms"]), a] *) (4) I had mistakenly suggested a way to handle derivatives of expressions that are constant with respect to the differentiation variable, in a way that would give the correct units (and zero magnitude) in the result. In[805]:= D[Quantity[5, "Meters"], Quantity[t, "Seconds"]] (* Out[805]= Quantity[0, 1/("Seconds")] *) It was pointed out that the "expected" units would be "Meters"/"Seconds". This too is under current discussion. And again, I can make no promises as to outcome, other than to state it is not being ignored here.I hope I have correctly ascertained all issues that arose. Again, if I missed any, please supply minimal examples. All the above examples are short and show clearly the indicated pathologies. Further examples should be similar. Rule of thumb, if they cannot be written in Mathematica copy-pastable form in the response proper, then they are not minimal. Moderator discretion may be exercised in editing or removing posts that fall outside the intentionally narrow parameters of this thread.
Answer
3 Replies
Sort By:
Posted 10 months ago
 This might be veering off the main subject, but referring back to David Park’s suggestion that units could be introduced at the end of an evaluation sequence, I think this has some merit. I’ve found that using units can slow down evaluation speeds massively (by up to several orders of magnitude). The slow down isn’t noticeable for trivial calculations, but becomes an issue when solving larger problems. Using QuantityArray can help. A bit. Sometimes. But, for large computations I’d consider deunitizing and reunitizing either side of the evaluation process.
Answer
Posted 10 months ago
 It was pointed out that the "expected" units would be "Meters"/"Seconds". Yes, because the D[ Length [meters], time [seconds] ] is a velocity, which of course may have the value zero (in the actual frame of coordinates), but a coordinate transformation can change this to a non-zero value. So in my opinion it must have the units of velocitiy .
Answer
Posted 10 months ago
 All,As the original ranter, let me now try to describe this bug with as little ranting as possible.Here is the entire issue in one line of code:  Quantity[200, "Kilograms"] * 0 == D[Quantity[200, "Kilograms"], t] I think both sides should equal "0", not "0 kg". And clearly, Mathematica should output "True" or "False". But V12 outputs:  0 kg == 0 That is, V12 appears unable to determine if the left hand side equals the right hand side, or not!To see this issue regarding the V12 Quantity function, consider:  Quantity[200, "Kilograms"] * 0 Which "incorrectly" returns:  Quantity[0, "Kilograms"] Now notice how that the D Function (Derivative) , which can also at times, involve multiplication of a Quantity by zero behaves very differently when it generates a "product" by multiplying the exact same Quantity as above, by zero:  D[Quantity[200, "Kilograms"], t] Here, correctly, though inconsistently with the first example, D outputs a value without units:  0 This is the Quantity inconsistency issue in a nutshell. Thanks for all for the help. And good luck to the Wolfram kernel guys in crafting a fix. Joe
Answer
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments