support comparison with zero

[aplavin]

This is convenient and unambiguous when constrained for scalar units

[codecov-commenter]

Codecov Report

Merging #640 (80feacf) into master (49623e0) will decrease coverage by 0.05%.
The diff coverage is 66.66%.

❗ Current head 80feacf differs from pull request most recent head be53711. Consider uploading reports for the commit be53711 to get more accurate results

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##           master     #640      +/-   ##
==========================================
- Coverage   89.06%   89.02%   -0.05%     
==========================================
  Files          16       16              
  Lines        1491     1494       +3     
==========================================
+ Hits         1328     1330       +2     
- Misses        163      164       +1     

Impacted Files	Coverage Δ
src/quantities.jl	93.97% <66.66%> (-0.34%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[cstjean]

By the same token, you could support addition by 0 and equality with 0. But unfortunately,

julia> 0u"m" == 0
false

so that'd be a breaking change.

[aplavin]

Equality with zero is already convenient and perfectly general in Julia: iszero(some_unitful_function()). It doesn't require any further operators, especially breaking.

As isless is bound with isequal according to their docstring, I agree that isless shouldn't be defined here. Can remove it, thanks for pointing out!
But there's no restriction on <, and being able to do some_unitful_function() > 0 would be an improvement.

[cstjean]

But there's no restriction on <, and being able to do some_unitful_function() > 0 would be an improvement.

I agree that it's convenient. I just worry about general consistency. You'd have that 0m < 0, 0m > 0, 0m == 0 all false. 0 <= 0m would also be false, which is particularly uncomfortable.

[aplavin]

0 <= 0m would also be false

Sorry, that's just an oversight! Can easily add <= as well. It's also non-breaking, same as <.

[cstjean]

Yeah, but then you'd have that x less-than-or-equal y is not the same as x<y || x==y

[sostock]

Some previous discussion: #455

Another point to consider: it feels inconsistent to me that 0 < 1m holds, but 0s < 1m doesn’t.

But it would be nice to have a more convenient method of comparing with zero.

[Ickaser]

There is also the philosophical question, raised in this book, that one can easily define negative units, so any sort of ordering operation like >/< only makes sense on a given unit scale. Allowing comparisons to a dimensionless 0 would lead to inconsistencies in examples like the following.

using Unitful
@unit negajoule "nJ" negajoule -1u"J" false
2u"J" > 0u"J" # true
2u"negajoule" > 0u"negajoule" # true

2u"J" > 0 # ????
2u"negajoule" > 0 # ???

This is perhaps a philosophical nitpick more than a "practical" one, since in this example we do have the following odd result as well:

2u"J" > 2u"negajoule" # true... 

But there is nothing "special" about any particular unit scale, particularly when it comes to things like energy that can only be defined with respect to some reasonable reference standard (and could therefore just as easily have an opposite sign).

[aplavin]

My point in this PR was purely pragmatical: if I want to check if a length or whatever other quantity is greater than zero, it doesn't matter what units this zero has. Currently, one needs to write some_function(its_arguments...) > zero(some_function(its_arguments...)) to perform this check instead of some_function(its_arguments...) > 0.

[cstjean]

Or ustrip(x) > 0.

Rereading the issue now, I wondered if it would it have impact on inference / code-gen? We'd go from <(::typeof(1.0u"m"), ::Int) that always-throws to maybe-throws. Also, you'd have to special-case affine-units, since -5°C > 0 is ambiguous.

All in all, while it's a very nice idea, feels like the complications outweigh the benefit/convenience.

[aplavin]

Or ustrip(x) > 0.

Can only use it in a package if it already depends on Unitful – not in generic code.