BUG: fix an issue where array functions would raise UnitConsistencyError on unyt arrays using non-default unit registries

[neutrinoceros]

Address the first part of #462

[jzuhone]

Could you explain a little bit more how this resolves the issue (sorry, it may be because it's late for me)?

[neutrinoceros]

the problem was that

• Unit() and Unit(registry=UnitRegistry()) have different hash, so they are considered as 2 separate unique units
• Unit() (or NULL_UNIT is this context) gets automatically inserted for non-unyt array-like data structures only because we want them to be treated as dimensionless

This condition makes it so all dimensionless units are treated as equal as long as nothing else is received.

[jzuhone]

What happens if the unit is dimensionless but is not the dimensionless unit? Say, what happens if it is Zsun?

[neutrinoceros]

What happens if the unit is dimensionless but is not the dimensionless unit? Say, what happens if it is Zsun?

that's good question. I think we should replicate the behaviour of basic operations (like addition), which I believe my current patch does. At the moment, 1*Zsun+1 or 1*Zsun+1*dimensionless are all treated as valid operations (in unyt 2.9.5 as well as 3.0.0). I must say I don't understand the result though, or why 1*Zsun + 1 != 1 + 1*Zsun, is this another bug ?

[jzuhone]

@neutrinoceros they are equal--I just checked:

import unyt as u
a = 1+1.0*u.Zsun
b = 1.0*u.Zsun+1
print(a)
print(b)
print(a == b)

gives:

1.01295 dimensionless
78.22007722007721 Zsun
True