Automatic Physical Units in Mathematica

I just published a Mathematica package that provides an alternative, richer implementation of units and dimensional analysis than the built-in units package. You can get it here. 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”.

First 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. It can convert between several hundred units and warn if a requested conversion is dimensionally inconsistent. But give it an input like…

and it does nothing with it until you specify that you want the result in a specific unit. 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”. All of the knowledge about units and Meter in particular is contained in the Convert command.
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. 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. 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.

My new data type is going to look (internally) like this:

And I am going to represent composite units with composites of the name in the second argument. For example:

So having created this type in my mind, what do I need to do to make it available to Mathematica? Well, nothing. 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!

We can proceed directly to teaching Mathematica what is special about the new type. Here is a typical rule to teach it what happens when you get powers of units.

The TagSetDelayed (shortcut notation /:) associates the rule with the symbol Unit. Generally it is good organization to keep the rules together, but it is also more efficient. More practically, it means that I don’t need to UnprotectPower. 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. The PowerExpand prevents us getting into silly units like Sqrt[Meter^2]], which is correct for complex variables, but not useful for positive real valued units.

Once evaluated, powers of unit data simplify automatically.

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. multiple argument, unit discarding or preserving, operate on quantity or quantity and unit type, and so on. 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. 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.

Here is one such example in action:

Of course, rules such as how the automatic axes labels work on visualizations of a grid of data in different units compatible only by column are a bit more complicated. None of these rules need any knowledge of the actual units; they can just make abstracted references to whether the input units are compatible and to a “common” unit for the output. For example, Min can only operate on units if they are all dimensionally compatible:

Once you have taught all the relevant functions in Mathematica how to handle Unit data in general, you are just left with the relatively simple task of describing how each unit behaves individually. That comes down to establishing a relationship chain between the definitions. In practice this can be simplified to a set of rules for each unit to and from a base unit representation, for example, that Unit[1, "Atmosphere"] Unit[101325, "Kilogram"/("Meter"*"Second"^2)]. Then any conversion can be reduced to converting to the base unit and then back to the new unit. Since unit values are now abstracted from all the logical code, we can just keep adding data. Over the course of a couple of very tedious days I added over 1,000 units, and you can add your own to the system too.

Finally, the internal structure isn’t necessarily what we want to enter or see. Fortunately, the parser and form matter in Mathematica are just two more commands that can be given rules for our new data type. We can hide the object structure in the same way that you never look at the copious data hidden inside InterpolatingFunction or CompiledFunction. So with a couple of rules for MakeBoxes and MakeExpression, any symbol for which there is a unit value will be parsed as a Unit expression, for example, the input “Meter” parses as Unit[1, "Meter"], but displays as “Meter”.

There are lots of details to doing a good job: efficiency considerations, syntactic sugar, auto-error correction or graceful fails under misuse, coverage of reals vs. exact numbers, and so on that take the package up to about 1,000 lines of code plus the 1,000 lines of unit definitions. But all of that is essentially handled in the same way as the three examples above—with additional rules for using this newly imagined symbolic data object under different circumstances.

I think the result is the most automated handling of units in any system. If it isn’t, let me know and I will add whatever rules are missing.

Here are some examples of the package in action.

Calculations involving units will automatically convert arguments into a suitable common default unit. In most cases the default is SI units.

Where input units are not compatible, no computation will be performed.

Composite units can be used by multiplying powers of units, and will also be handled automatically.

SimplifyUnits will try to find simpler equivalents to composite units.

Most operators, for which unit-based quantities make sense, will automatically handle units.

Some data constructors can support ranges or intervals using unit-based quantities. For example, here we generate 10 random quantities between 1 Yard and 1 Meter.

Or generate values between 10 Meters and 13 Yards in 1 Foot steps.

Many plotting routines will handle units, and will usually display the resulting units as AxesLabel.

Unit-based quantities have a head Unit, which is not shown in StandardForm.

In TraditionalForm, traditional short labels, with full-name tooltips, are used for the units.

You can convert quantities to specific units.

Or to the most appropriate unit from a list.

A large collection of pre-defined sets of units is available.

The available named unit sets is given by:

You can see or change the members of a particular set or create new sets.

Sweet package, but it seems to be a one way street. I can get MMA to take Meter Second^-2 Kilogram and give me Newton, but i cannot get it to take Newton Kilogram^-1 and return Meter Second^-2. Thoughts?

A trivial question: where should I save Mathematica packages so that Mathematica can find them? I’m using Mac OS 10.6 and I saved this package in ~/Library/Mathematica/Packages and Mathematica says it can find it (“$Failed”).

I downloaded the AutomaticUnits zip file and installed it as a Mathematica application on my system. It seems to work as advertised. Thank you very much for making this package available to Mathematica users.

One problem has surfaced with the installation. Documentation for automatic units topics appear in the Documentation Center when I search, but I can’t open any of the references. For example, if I search on “UnitSet”, I get hits for UnitSet, $DefaultUnitSet, Automatic unit conversion, Convert, Working with units, and Unit. However, when I click on any of these, I get an error dialog. Say I click on UnitSet, then Mathematica message window reports:

Documentation`HelpLookupPacletURI::link: Could not resolve paclet URL paclet:AutomaticUnits/ref/UnitSet to a document.

@Morton Goldberg
This is related to the Paclet system failing to register the various PacletInfo.m files or their relative locations has changed.

1) Make sure that the contents of the AutomaticUnits zip file are all in the same relative positions.
2) If you have installed other Paclet extensions, make sure there is not a faulty one interrupting registration by temporarily removing them (and any PacletInfo.m files that don’t belong.)

If it doesn’t sound like any of that applies to you, then give our technical support guys a call and they can talk you through the problem.

This is very good but why hasn’t this been part of Mma for years? I’ve been using another product for this type of work. I know of two products that have this built in. Why is it that Mma is always playing catch up with features that already exists elsewhere?

This is really cool. It’s both useful in and of itself, and as an example of how to integrate something into the existing Mathematica framework.

Thank you for sharing it.

I was just wondering, when you are developing a large package like this, do you generally use the notebook interface all of the time, or do you edit the .m files and re-evaluate the cells which load them each time you want to make a change and test it?

Please feel free to direct me to anything published on the testing and debugging workflow (I haven’t found very much in the documentation).

I miss some two things to make it perfect (for business use):-)
One is date arithmetic, the other is currency arithmetic.

Ad1) Date arithemtic
——————————–
DatePlus and DateDifference should be overloaded to include “time periods” (like 10 Day, 1 Month etc.). In my opinion we need a date type Date[] for “time points”, so we could i.e. use Subtract instead of DateDifference for d1 – d2 to get “time periods” as result (e.g. 25 Days).
Also, 1 Week + 2 Day should not (only) result in Seconds. It would be nice to have a “set of units” as a single result (e.g. {Year, Day} to print as: n Year + m Month).

Ad2) Currency arithmetic
————————————–
Are there plans to include the Money dimension, like in W|A? I mean not only to calculate within one currency like 100 USD + 25 USCents, but to calculate between currencies like 30 USD + 10 EUR in MMA, not only W|A.

@ Morris
Most of the work was done in the Wolfram Workbenchhttp://www.wolfram.com/products/workbench/
It automatically reloads the package as you save changes allowing you to test them in the notebook immediately. Though most of the testing I did was via the automatic test suites feature of Workbench, It is very reassuring to make an important change (eg Plus or Times) and immediately see that 1000 tests have not broken.

@ Drago Ganic
1) I didn’t really consider the mixed return units n Year+ m Month (it is the same issue wanting a length in feet and inches. You would need a function to return the mixed units as a list not a sum since 1 Foot+2 Inch is designed to resolve automatically to 14 Inch.
eg
ToMixedUnits[1 Meter, {Foot,Inch}]->{3 Foot, 3.3 Inch}
I might implement that in a future update.
2) There are no pre-defined dimensions, so you can use it for money right now. Do
DeclareUnit["USD"];
DeclareUnit["Euro",1.33 USD];
DelcareUnit["GBP",1.58 USD];
Then
Euro+GBP-> 2.91 USD
Convert[Euro, GBP]->0.84 GBP
Of course, you will need to change the values in your definitions daily, so probably would not want to hard-code the values like this example, but define them dynamically with calls to the new WolframAlpha command, or FinancialData.

Very nice package. I’ve been using a similar approach though reduced to only “my” units implemented in a more ad hoc way.

I’ve been wondering if there was a way to have the syntax highlighter recognize certain symbols in different colors, such that you could more easily distinguish the “units-symbols” from the other symbols in input? For example highligting Meter in bronw instead of black as it does for Plot.

Division and Power do not automatically trigger a simplification except in the case of direct cancellation. Otherwise it would be impossible for you to use Pascal Second Meter^2/Kilogram should you wish to. Should you add it (for example) to another velocity (in this case) the unit would be converted. You can force it out of this unit with Convert[%,"SI"] or Convert[%,"Imperial"] etc

SimplifyUnits should clean it up too, but there is a rather careless bug which I will fix shortly, In the meantime you apply the fix with
SimplifyUnits[AutomaticUnits`private`a_] :=
AutomaticUnits`private`a /.
AutomaticUnits`private`expr_Unit :>
SimplifyUnits[AutomaticUnits`private`expr]

It is incorrect to put the units in italics (in TraditionalForm). According to international standards such as the SI, the unit symbols should be upright. Variables and quantity symbols are in italic type.

@cipri
Not a “bug” but a consequence of the design of NumberForm (and all the *Form commands for that matter). One could argue about whether it is a good design, but that is a different question!

You get the same effect with
NumberForm[4, 3] + NumberForm[2, 3]
The reason is that the Head NumberForm remains invisibly wrapped around each of the quantities, and there are no rules for the behaviour of NumberForm under Plus (or any other function).

Generally you want to use any *Form command as the very last step for display, and not introduce them early into the computation.

Hello,
This package is now essential to my use of Mathematica. I added the unit “RPM” (revolution per minute) in “alternative.m” and maybe you should add it in the next version.
However, when I work with dimensionless numbers (in fluid mechanics for instance), Mathematica doesn’t simplify the result and I have to use SimplifyUnits to see that in fact the number is dimensionless.
Could you make it automatic in the next version of this package?
Thank you again for this package!
C Cottin

An other problem I encountered
I define
omega= 130 RPM
r=1 Meter
V=omega*r is in m/s so no problem so far!
Now if V2=V Tan[Beta]
and Beta=30 Degree
I have V2 in Meter*Radian/Second…
Could you look at it for the next version!
Keep up the good work!!!
C Cottin

In my design I have taken the slightly controversial decision that angle is a dimension rather than a dimensionless multiplier. This means that you need to divide through by the appropriate angle to make the
velocity = angular velocity x length
formula work. But doing so should make it more robust to angular velocity being provided in something other than RPM and avoids consistency confusion between things like radians and steradians.

Thank you for your answer!
I understand your choice so I will divide the result by Radian.
I have now a problem with Plot!
I defined a function:
Hi[x_] := 8 (U2 (U2 – (0.88 x)/(2 \[Pi] r2 b2 Tan[\[Beta]2])))/g
This function works without problem:
Convert[Hi[0 Liter/Second], Meter]
yields
3220.54 Meter.
But when I type:
Plot[Hi[x], {x , 0 Liter/Second, 1000 Liter/Second}]
it yields

I have a problem with the Round function. While rounding to integers works with Round[x], I cannot round to real numbers with a specific number of digits, e.g. Round[x,0.1]. Is there a solution to this problem?

Very nice package. Unfortunately it’s not compatible with
another package PhysicalConstans (is it possible to make
them work together),
Besides this I found a small bug in Planck units –
PlancTemperature has dimension of Meter after converting
to SI units.
Regards

@Pawel
My pacakge was designed to be an alternative to the built in units, and unfortunately PhysicalConstants explicitly loads the built in package.

You can make AutomaticUnits mostly play nicely with PhysicalConstants by editing the first non-comment line of
$TopDirectory\AddOns\Packages\PhysicalConstants\PhysicalConstants.m
From
BeginPackage["PhysicalConstants`", "Units`"]
to
BeginPackage["PhysicalConstants`", "AutomaticUnits`"]

It generates several errors for several physical constants which I have added as units to my package, but otherwise works fine. (Though I have done only very basic testing).

I am just about to submit an update to the package which will fix the Planck bug along with all the other fixes and suggestions that appear in these blog comments.

@Steffan
Plus in Mathematica is orderless and so 20C+5K is the same as 5K+20C. The choice of unit when mixed units are added is governed by the value of $DefaultUnitSet which is set to “SI” by default. And the SI unit of temperature is Kelvin. You can change either the value of $DefaultUnitSet to a custom UnitSet which has Celsius as a member rather than Kelvin to get the behaviour you want.

You should consider that Kelvin is not only the unit of the absolute temperature, but also the unit of a temperature difference. So if I add a 5K temperature difference to 20Celsius, the result should be 25Celsius.
This is the standard nomenclature in any thermodynamic calculation. It would be a problem if AutomaticUnits cannot deal with it (e.g. Mathcad can…).

There is a basic conflict of meaning for the units with non-zero origin. While the natural interpretation of 0C is 273K, when you look at, for example temperature gradiate 1 C/Meter is probably understood to be the same as 1 K/Meter. Both the original Units package and my update deal with the by providing two convertions. Most (Convert, SI, etc) assume only scale conversion 1K=1C and the command ConvertTemperature is provided to respect the non-zero origins of some temperature units. There are probably other designs that could work, but this felt more natural to me than attempting to automatically spot special cases giving conversion behaviour that depended on the unit.

I think Mathematica should treat the units physically correct, i.e. 0C is 273.15K. A temperature gradient is always expressed in K/m, C/m should yield an error. In the same way, 0C + 0C should yield an error, as it has no physical meaning (the result in Mathcad is 273.15C!). Probably, some “hard” programming is inevitable in this case.

The updated version of the package is now available athttp://library.wolfram.com/infocenter/MathSource/7655
It addresses, most of the issues discussed in the comments.
Drago Ganic’s suggestion is implemented as a command UnitList eg
In[2]:= UnitList[2. Kilometer, {Mile, Yard, Foot, Inch}]

…you can also change the defaults using the palette that comes with the package. You can find that on the Palettes menu once the package is installed.

I should correct the last comment. Using “Imperial” will choose the most appropriate unit out of the set, which is only Foot for lengths around a Foot, it will switch to Yard for larger lengths and Inch for smaller. To ensure Foot is always used do
UnitSet["MySet"]={Foot, Second, … the other dimensions…};
$DefaultUnitSet=”MySet”

Hey all – I have a minor problem if I load the PhysicalConstants package and this awesome AutomaticUnits package. I get errors that BohrRadius, EarthMass, EarthRadius, and PlanckMass are redefined. Is there an easy remedy for this?

This is a fantastic package! It really helps in validating my equations when I see the right units coming out.

I wonder if you have looked at the open source DesignerUnits Mathematica package. I have not used it, but it appears to have the same goal. (http://designerunits.com/overview)

I am using AutomaticUnits 1.0.1, and I believe I have found a hole in the package’s definition for either Joule or Kilogram.
Try this input:
BoltzmannConstant = Unit[1.3806504`*^-23, Joule/Kelvin]
v[T_, m_] := ((8*BoltzmannConstant*T)/(Pi*m))^(1/2)
SimplifyUnits[v[300 Kelvin, 6.64648*10^-27 Kilogram ]]
I would expect an output of Meter/Second. Instead I get (Joule^1/2)/(Kilogram^1/2). Indeed these units can be simplified to Meter/Second, but AutomaticUnits does not see this.

@Alex
For SimplifyUnits, I attempted to minimize the number of unit names only. As such (Joule^1/2)/(Kilogram^1/2) is considered as simple as Meter/Second. Your example is good motivation for considering exponents as well, and perhaps also giving preference to base units. I may add that to a future version.

Hi,
First, thanks for this excellent package. When I try to use units like Joule/Mole (common in Chemistry), the package automatically provides the answer in Joule. Is there a way to stop this conversion from happening? I tried to multiply this by the Avogadro Number, however in the definition, there is per Mole and whatever I define as Avogadro Number becomes 1.0. Is there a way to work around this?
Thanks,

I like AutomaticUnits, but had to use PhysicalConstants too. As a work-around hack to make them play nicely, I temporarily added a definition to the BeginPackage command:

(*Force PhysicalConstants to use the correct units package.*)
Unprotect[BeginPackage];
BeginPackage["PhysicalConstants`", "Units`"] =
BeginPackage["PhysicalConstants`", "AutomaticUnits`"];
< 1, Meter -> 1, Second -> 1, Kelvin -> 1,
Kilogram -> 1};
Then when I have to do some numerical integration, I use
var /. noUnits to get a dimensionless quantity that can be integrated (I have to figure out the resulting units myself, but that’s okay).
Is there an existing list that I could use already, or a function that can do the replacement for me?

Finally, AutomaticUnits takes a fairly long time to load (a couple of seconds). Would removing/disabling some of the more esoteric units help speed things up? How would I do this?

@Wade
My comment to Pawel, further up the comments, addresses the Physical Constants issue.

Faster loading you can remove all of the Get statements near the bottom of AutomaticUnits.m
You can load each of those later, if you need them. Be aware that there are some dependencies, so best to leave the first 5-10 even if you think you don’t need them.

I did do some optimization on the initialization of units, so loading them later will take more total time than loading them at the start.

For super fast, use DumpSave to make an .mx file version of the package.

Thanks for providing this package. Something like it has been needed for a long time.

I’d like to note a couple documentation issues. Tutorial links to “AutomaticUnits Package” or “Units Package” in documentation for this package produce the following error:

Documentation`HelpLookupPacletURI::link:
Could not resolve paclet URL paclet:AutomaticUnits/tutorial/Units to a document.

Also, one of the items found when searching for “AutomaticUnits” is “Automatic unit conversion (Automatic Units Guide)”, but this link produces the following error:

Documentation`HelpLookupPacletURI::link:
Could not resolve paclet URL paclet:AutomaticUnits/guide/AutomaticUnitConversion to a document.

I think these must be errors in the documentation files, because there are no files named “Units” of “AutomaticUnitConversion” in the AutomaticUnits folder or subfolders. However, there are files named “WorkingWithUnits” and “AutomaticUnits”, which seem to be the ones intended, respectively.

I can’t seem to get it to work with Manipulate. Has anyone had any success using parameters with units using Manipulate. It generates an error because it seems to be trying to add a dimensionless number to one with units.

Thank you for this nice tool!
The Unit tool work fine and I have integrated the palette, this work also fine.
But i have a problem with the help document…
Documation Center can find the main document without any problems, when I click to a link in the main document I receive a error message…
“The file you tried to open was not found or could not be opened.”

“Documentation`HelpLookupPacletURI::link: Could not resolve paclet URL paclet:AutomaticUnits/ref/UnitSet to a document.”
but I don’t change any path in the automatic unit folder…
I hope, you can help me….

Pertaining to my comment a few weeks back, is there a way to add a legend when using Show[] to plot with units? So say measurement1={300 Inch, 10 Meter, 10 Yard}; and measurement2={200 Inch, 8 Meter, 8 Yard} and I want those names to appear on my ListLinePlot

Is there a way to use FindRoot with units? I’m solving the radiation equation with a Temp^4. Solve takes too long/doesn’t finish the system of equations solution. It gives the error that {T,10Celsius} is not a number or array of numbers.

Is the only way to resolve this to divide by the units for each parameter? Thank you

FindRoot is not ‘units aware’ in my package, which makes the best option to discard the units completely with something like
FindRoot[DropUnits[x Meter], {x, 3}]
If I do another update to the package, I will try and add support for this function.

I have one set of problems with the package. AvogadroConstant, MolarGasConstant, FaradayConstant, and MolarVolume all have the wrong value. Specifically, the value given by the package is the correct value divided by Avogadro’s Number.

For example, AvogadroConstant has the value of 1 rather than approximately 6.022×10^23
In[6]:= AvogadroConstant
Out[6]= 1.

I did not treat dimensionless units as units in this package, except for angles. Doing so may give you the functionality you want. Try commenting out the line
Mole = 6.0221367*10.^23
And add in to the SI.m declarations
DeclareUnit["Mole", Unit[ 6.0221367*10.^23,"Molecule"]
Instead of “Molecule” one could do this more generally and use “Dimensionless”, eg if you did the same with Dozen, BakersDozen etc the conversions like
Convert[3 Dozen, BakersDozen] would work- which they don’t now. But you would lose the ability to do
Dozen+10
That would have to be entered
Dozen+Unit[10,"Dimensionless"]
I never thought through a good design for that, so left them as pure numbers.

Removing the lines with Mole=6.022*10^23 fixes the problem of AvogadroConstant etc. having the wrong value.

However, the idea of declaring Mole to be a unit of type “Dimensionless” breaks converstions to units like kJ / Mole (Kilo Joule / Mole). For example Convert (ElectronVolt, Kilo Joule / Mole) now fails because the units are incompatible. They both should be units of energy but with the definition of Mole as Dimensionless, Kilo Joule / Mole is of type energy / dimentionless.

It seems what is needed is the concept of a real dimensionless unit that would be a type of unit that doesn’t change the type of the unit. I thought a little about modifying the CompatibleUnitQ function so that “Dimensionless” was treated as a special case. I suspect you might have better ideas about how to do the design and look forward to your comment.

By the way, Molar specific units like kJ / mole or kCal / mole are commonly used in physical chemistry. I hope you can find a design that will accomodate these commonly used units.

Some feedback, I got from the Wolfram Alpha team is that Mole is not dimensionless in the official SI, but is a base dimension itself. As such ElectronVolt should not be compatible with Kilojoule
/ Mole

There is apparently discussion of adding another quanity unit – tentatively called the “Uno” to SI to deal with this.

It would still be nice to handle units more like MathCad does. There, I can take any *output* result, append it with millimetre, metre, kilometre, etc. and the numrerical result is changed accordingly. Saves a lot of the Convert, Reduce, … functions that do nothing but clutter up an otherwise readable worksheet.

You can append a unit, after the event using this package eg
x=RandomReal[]
returns a number, you can then just use
x Meter
as a unit based quantity.

If however, you are suggesting that editing the result should automatically change the stored value, then I would have to disagree that that is a good idea. That would hide the process by which the answer was arrived at and reduce reproducibility. It is for this reason that editing output changes it into a new input cell – so that you can see that it there was manual intervention.

Thank you so much for this package. When using it for the first time I, like a couple of others above, wanted the units to stand out. Thank you for pointing us to the makeboxes declarations to do this change. For those of us that do not do serious coding, I might take a day or more to figure out exactly what to do. Since I have no qualms about italics, and I almost exclusively use standardform, I would like to point out to others the change you can do to make this happen. I commented out the line,

OK, the color purple might be overboard, but I like it. As you notice I also like the traditional form unit names so I make the replacement even for standardform. It changes the palette buttons as well, but as a physicist I’m OK with that.

For Richard who wants more MathCad like functionality (and ridding myself of this program is why I came here in the first place), I wholeheartedly agree that the readability can suffer when adding unit handling. But I agree with Jon that the base paradigm of Mathematica over MathCad is the way to go. I offer this tip, make an input alias for an operator without meaning in Mathematica. I actually put

x_ \[Congruent] y_:=Convert[x,y]

in the package so that it loads at the same time. Now conversions are accomplished in a postfix way, improving readability, with only the use of two keys (in the case of congruent, esc === esc)!

For Jon, perhaps a checkbox in the palette to do the italics and traditional form output would appeal to more than only me. Also, and this may be addressed above, when I have exactly 1 of a quantity (1 Meter) I seem to lose the interactive output ability to click and change units.

It has also become incompatible with 9 due to a name conflict, though there is an easy fix: Open the file AutomaticUnits.m and do a search and replace on all occurrences of “CompatibleUnitQ” change it to a different word, I suggest “DimensionCompatibleUnitQ”. Replace the file with the modified version.

Because Degree was a pre-existing symbol, my package declares its dimensioned value using the option CreateSymbol->False, to prevent existing code which uses the symbol being broken. This means that you must enter degrees using the InputForm version IE
Unit[9,"Degree"]+9ArcMinute
There are several other units that have this type of name conflict eg Circle, Span, Last, Drop, Gamma, Gray etc

I strongly disagree with the comment that the “package is now largely obsolete as similar functionality is included in Mathematica 9″. The calculations with units using AutomaticUnits is still much more straight forward, faster and elegant compared to the new implementation in Mathematica 10. However, at least the DeclareUnit function seems to be incompatible with version 10. Any fixes for that?

Thаnks for every other informatiᴠe site. Whᥱrе else could I get that type of
infо written in such ɑn ideal wɑy? I have a challenge that I am
simply now operating on, and I have been on the look out for such info.