Changed the - signs to underscores. I think that addresses your comments about the string representations.

Thanks for the submission. I think it needs to include unit tests before we can consider merging.

Would it make sense to instead define a Log10Unit class, such that

bel = Log10Unit('bel', ...)
decibel = UnitQuantity(..., bel/10)
bel_milliwatt = Log10Unit('bel_milliwatt', ...)
decibel_milliwatt = UnitQuantity(..., bel_milliwatt/10)

?

That makes a lot of sense. I will go on and remove UnitLogIntensity and UnitLogPower in favor of Log10Unit, then. Would it make sense for the Log10Unit constructor to keep track of the original linear units, for example:

bel = Log10Unit('bel', ..., linear_units=1)
bel_milliwatt = Log10Unit('bel_milliwatt', ..., linear_units=milliwatt)

Could you expand on that? I don't understand how that information would be used.

It's an incomplete thought, but I was wondering if it would be useful to have a way of converting logarithmic units like dBm back into ordinary units like mW. For example, I imagine an expression like pq.Quantity(-40, pq.dBm).linear_units would return the same thing as pq.Quantity(1e-7, pq.W), whereas attempting to linearize a quantity like pq.Quantity(-40, pq.dBm) / pq.meter would raise a ValueError, similar to trying to convert between incompatible units.

Ah. This is a bit tricky, because now you are getting into logarithmic scales, and the quantities package makes no attempt to support measurement scales. I could imagine specifying the base:

LogUnit('bel', base=10, ...)

which could be used by a function (not a method) provided by the logunits module to convert a linear quantity. But it would need to be documented that it is up to the user to ensure that the conversion is appropriate.

I doubt this would be useful, as a subtraction of two log quantities would
result in a log quantity with different units. I expect once you go down
this rabbit trail you'll find that things are increasingly difficult.

David

On Sat, Apr 13, 2013 at 12:57 PM, Chris Granade notifications@github.comwrote:

It's an incomplete thought, but I was wondering if it would be useful to
have a way of converting logarithmic units like dBm back into ordinary
units like mW. For example, I imagine an expression like pq.Quantity(-40,
pq.dBm).linear_units would return the same thing as pq.Quantity(1e-7,
pq.W), whereas attempting to linearize a quantity like pq.Quantity(-40,
pq.dBm) / pq.meter would raise a ValueError, similar to trying to convert
between incompatible units.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/58#issuecomment-16339661
.

David Roundy

Fair enough. Going back to the basic idea of log units, however, without any attempt to convert to any other scale or measure, I think there's still utility due to how logarithmic units can come about in the analysis of circuits and the control of electronic hardware. For instance, it's common to talk about the attenuation due to a circuit element in units of dBm, or to request that the output power of a device be set in logarithmic units.

In particular, my main use of the quantities package at the moment is in my contributions to the dev branch of cgranade/gpibusb-comm_code, where hardware properties are get and set using quantities.Quantity to ensure that the hardware driver converts the units for transmission to the device in a way that is transparent to the caller. For devices that accept power settings in log units, the dimensionality mismatch errors raised by quantities.Quantity.rescale() prevent a user from specifying linear units, so that the user must explicitly write how a quantity for sending to a device is to be interpreted. If this usecase is outside the scope of quantities, then that makes sense as well.

closed based on previous comments