Here is the collection for “functions of one argument that apply directly to the quantity only and remain in the original unit.” I use it to extend each function in this group ( Abs through to Round) to handle units in the same way. Once you collect them into groups of the same type, then you can usually come up with a single rule that can be used for each function in the group. multiple argument, unit discarding or preserving, operate on quantity or quantity and unit type, and so on. When you think about the range of mathematical functions that can be applied to units, they mostly fall into a fairly small number of categories that are roughly all the permutations of: single vs. Once evaluated, powers of unit data simplify automatically. The PowerExpand prevents us getting into silly units like Sqrt], which is correct for complex variables, but not useful for positive real valued units. The rest is a pretty straightforward pattern that says if we apply a numeric power to a unit, the operation slips inside the Unit object and applies to each of the components of the object. More practically, it means that I don’t need to Unprotect Power.

Generally it is good organization to keep the rules together, but it is also more efficient. The TagSetDelayed (shortcut notation /:) associates the rule with the symbol Unit. Here is a typical rule to teach it what happens when you get powers of units. We can proceed directly to teaching Mathematica what is special about the new type. Really, nothing! I can already enter and store data in that type and write functions that recognize that type because “type” is just an arbitrary symbol used as a wrapper for a collection of contents, and Mathematica eats symbolic data for breakfast! So having created this type in my mind, what do I need to do to make it available to Mathematica? Well, nothing. My new data type is going to look (internally) like this:Īnd I am going to represent composite units with composites of the name in the second argument. Just as in the existing version, the only function that needs to know about the ratio of Meter to, say, Inch, is Convert, though that might be invoked, in an abstracted way, by other commands. In order to do this in an extensible way, I don’t want to teach all these commands about Meter specifically, but I will create a new data type for units, so that I can teach the Mathematica commands about units abstractly. So in this package I want as many of Mathematica‘s commands as possible to do sensible things automatically when they encounter unit-based quantities. All of the knowledge about units and Meter in particular is contained in the Convert command. The core reason is that it doesn’t teach the system, as a whole, anything about units, or even that the symbol “ Meter” is any different than the symbol “x”. But give it an input like…Īnd it does nothing with it until you specify that you want the result in a specific unit. It can convert between several hundred units and warn if a requested conversion is dimensionally inconsistent.

Aside from being a really nice extension to Mathematica, it is also an interesting case study in adding a custom data “type” to Mathematica and extending the knowledge of the built-in functions to handle the new “type”.įirst I have to explain the point by answering the question, “What’s wrong with the built-in units package?” Well, there is nothing actually wrong with it, it just doesn’t apply Mathematica‘s automation principles. Wolfram Knowledgebase Curated computable knowledge powering Wolfram|Alpha.I just published a Mathematica package that provides an alternative, richer implementation of units and dimensional analysis than the built-in units package.

Wolfram Universal Deployment System Instant deployment across cloud, desktop, mobile, and more. Wolfram Data Framework Semantic framework for real-world data.

Wolfram mathematica documentation plot