I’m posting this one because I’ve encountered strange behaviours in logarithmic astropy units. It looks like with the most recent version of astropy (conda create -n test_env astropy) the issue still persists. I’m not sure if it’s a bug, so I first wanted to check if that’s an intended behaviour of astropy.units.dB
Let’s take the base example:
from astropy import units as u gain = 5 * u.dB(1)
This produces a nice 5 dB value. However, let’s in case if we have some calculations done before:
gain = ((15*u.m)/(3*u.m)) * u.dB(1)
or gain = ((15*u.m)/(3*u.m)).to(u.dB(1))
The result is 6.989700043360188 dB, which is somewhat unexpected as it looks like “* u.dB(1)” automatically applies the 10*log10 operation.
Another example is
power = 5*u.dB(u.W)
Which produces a nice 5 dBW value. However, the same u.dB(u.W) can’t be applied to
power = ((15*u.m)/(3*u.m)) * u.dB(u.W)
Which will just throw an error that they are of different types and can’t be multiplied.
I’m aware of u.Decibel and u.DecibelUnit, but I wonder if u.dB was intended to operate this way.
As a workaround, if your calculation is guaranteed to be dimensionless, you can call .to_value(u.one) to turn it back to a simple number before attaching the decibel unit.
Hi ayshih, many thanks for your replies! Regarding the workaround - indeed, that’s very similar to what I did in my project. I just added .value to get the raw number.
Sure, calling .value instead of .to_value(u.one) can be fine as long as you’re certain that that the units exactly cancel out, including not having stuff like u.m / u.mm.