This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Harvey, Sorry for the delayed reply. I've been busy with other things and I wanted to give your email a considered response. > I am pleased to see you have produced a new udunits. I gather udunits-2 > is still in beta release so I hope some changes are still possible. > > I had also been thinking about things like logarithmic units, so I > thought I would share some of these ideas. In fact this is the first > real task in my new (from today) role as a CSIRO honorary fellow after > retiring last Friday. I considered posting to the netcdf and/or udunits > groups, but decided to start with a more private communication with you > and Russ. Honorary fellow, eh? Sounds nice. Does that mean you have authority but no responsibility? :-) > Function ut_raise should be modified so the power argument is double > rather than int. This simple change would allow operations such as > square-root, which occur when doing things like calculating the side of > a square from its area. You're right. I forgot to create an inverse to raising a unit to an integral power. I'd rather not generalize ut_raise() to accept floating-point exponent, however, because that would lead to problems in determining the rational number the user had in mind (e.g., 2/3, 3/4, 7/9). It could be done by limiting the allowed set of rational numbers to a select few -- but the elements of that set would be arbitrary. I think I'd rather add two more functions: ut_root() and ut_power(). ut_root(ut_unit unit, int i) would take the "i"th root of "unit" and ut_power(ut_unit unit, int numer, int denom) would take "unit" to the power "numer/denom". Therefore, ut_raise(unit, i) and ut_root(unit, i) would be equal to ut_power(unit, i, 1) and ut_power(unit, 1, i), respectively. > There is a need for functions named say ut_exp and ut_log to convert > from and to logarithmic units. This would enable one to do things like > multiplying by adding logarithms, then taking the anti-log (exp). One > might want to do this to decrease the chance of overflow in calculating > a geometric mean. I suggest storing an int representing the number of > applications of function exp(), with negative values representing the > number of applications of the inverse function log(). Thus unit "pH" > would have the value -1. Value -2 would mean log(log()). The function ut_log(ut_unit unit, double base, ut_unit reference) already exists to convert a non-logarithmic unit to a logarithmic one. I can create a new function, ut_exp(ut_unit unit), to return a logarithmic unit to a non-logarithmic one. I'm afraid I don't see the need, however, for units that are associated with quantities that are, for example, the logarithm of the logarithm of a physical quantity or the exponent of the exponent of a physical quantity. Do you have an example of a formula or mathematical expression in which this is the case? > Cheers to all at Unidata, You too. Regards, Steve Emmerson Ticket Details =================== Ticket ID: ONU-754617 Department: Support UDUNITS Priority: Normal Status: Closed