Comparisons with Inf fail

[JeffFessler]

This comparison fails:

1u"m" < Inf
ERROR: DimensionError: 1.0 m and Inf are not dimensionally compatible.

where I think most users would expect to be true because ±Inf should not need to have units.

Now x = 1u"m"; x > 0 also fails but here we have the acceptable alternative x > zero(x).
But there (apparently) is no analog like infinity(x) so we are stuck with Inf.

These are the key lines:

Unitful.jl/src/quantities.jl

Line 265 in 1e78e6b

@eval ($i)(x::AbstractQuantity, y::Number) = ($i)(promote(x,y)...)

Unitful.jl/src/quantities.jl

Line 274 in 1e78e6b

@eval @inline ($j)(x::AbstractQuantity{T,D1,U1}, y::AbstractQuantity{T,D2,U2}) where {T,D1,D2,U1,U2} = throw(DimensionError(x,y))

That last line could check for ±Inf instead of always throwing an error. The performance hit would be small because that line only gets used in the error condition. Would a PR be welcome?

I search all issue for Inf and found nothing and found just 2 issues that concern isless: #399 #30

[giordano]

because ±Inf should not need to have units.

Why?

[JeffFessler]

Well, why should it have units? And if it should, then why is there no infinity(x) like there is a zero(x)?

The above is a MWE. Here's the real back story.

using Unitful
using Plots

import Dates; d = oneunit(Dates.Day)
x = d * (1:5)
scatter(x, 2x) # works fine

x = 1u"m" * (1:5)
scatter(x, 2x) # fails due to Inf comparison

If a plot vs dates works, so should a plot vs meters...
Of course I could take this specific issue up over at Plots, but I think Unitful would be more user friendly if comparisons with 0 and Inf just worked (even without units), in the same way that Int16(0) < 1.0f0 just works. It might help things just work in other places that make such comparisons, with no obvious downside over an error message.

[giordano]

Well, why should it have units?

Because it's a number just like all others? I don't see any reasons why it should be special.

then why is there no infinity(x) like there is a zero(x)?

Because no one took the time to do that? But zero and one are important as they are the neutral element of basic arithmetic operations, there is no such argument for infinity

[JeffFessler]

Because it's a number just like all others? I don't see any reasons why it should be special.

I disagree that it is "just like all the others" but I'll take this as a no on the PR.
https://en.wikipedia.org/wiki/Extended_real_number_line
Thanks for the replies.

[giordano]

My point is: if you have an infinite length coming from operations (e.g., 1 / 0u"m"), that does have the units attached and so no problem with that, otherwise why would you expect to be able to compare Inf (a pure Float64) with a length? Why would that be any different from any other Float64?

Do you have a practical case where this is an issue?

[JeffFessler]

Why would that be any different from any other Float64?

Inf is different from other "numbers." Try this: Inf == 2Inf. It is true.
There are only 3 cases where x=2x, namely, 0 and Inf and -Inf.
That is at least some rationale for treating 0 and Inf differently.
I do not want to take more of your time debating the meaning of infinity.
https://math.stackexchange.com/questions/36289/is-infinity-a-number
I already described a practical case with a plot above.
Putting infinity aside, you really could make Unitful more user-friendly by allowing comparisons with 0 without insisting on units on 0, in the same way that Base Julia allows one to compare 0//1 with 0.0f0 without forcing the user to do their own type conversion.

Here's the code in case anyone else would find it convenient.

# extended version of _lt that gracefully handles {0, ±Inf} < y
function Unitful._lt(
    x::Unitful.AbstractQuantity{T,NoDims,U1},
    y::Unitful.AbstractQuantity{T,D2,U2},
) where {T,D2,U1,U2}
    y1 = y / oneunit(y)
    x == Inf && (return false) # Inf < y
    x == -Inf && (return -Inf < y1) # -Inf < y
    iszero(x) && (return 0 < y1) # 0 < y
    throw(Unitful.DimensionError(x,y))
end

# extended version of _lt that gracefully handles x < {0, ±Inf}
function Unitful._lt(
    x::Unitful.AbstractQuantity{T,D1,U1},
    y::Unitful.AbstractQuantity{T,NoDims,U2},
) where {T,D1,U1,U2}
    x1 = x / oneunit(x)
    y == -Inf && (return false) # x < -Inf
    y == Inf && (return x1 < Inf) # x < Inf
    iszero(y) && (return x1 < 0) # x < 0
    throw(Unitful.DimensionError(x,y))
end

# Tests:

m = 1u"m"

using Test
@testset "0,Inf" begin
    @test m < Inf
    @test -Inf < m
    @test !(m < -Inf)
    @test !(Inf < m)

    @test Inf > m
    @test m > -Inf
    @test !(m > Inf)
    @test !(-Inf > m)

    @test 0 < m
    @test m > 0
    @test -m < 0
    @test 0 > -m

    @test_throws Unitful.DimensionError m < 2
    @test_throws Unitful.DimensionError 0u"s" < m
end

So the good news here is that with this addition one can support the convenient form 0 < 42u"m" in the way that one would expect, as well as the more rigorous form 0u"m" < 3u"m".

The bad news is that this got the plot example above to get a bit farther along before throwing an error somewhere in uconvert. So I give up for now.

[giordano]

Inf is different from other "numbers." Try this: Inf == 2Inf. It is true.
There are only 3 cases where x=2x, namely, 0 and Inf and -Inf.
That is at least some rationale for treating 0 and Inf differently.

I honestly fail to see what you want to prove with this argument. In particular, why would you want to strip out the the unit properties from the quantity when comparing with Inf. By your argument we should do the same for 0 which is also a strong no from me. I really don't understand why infinity or zero shouldn't respect the "unit dimensionality" of quantities.

I already described a practical case with a plot above.

Why don't you use UnitfulRecipes.jl?

[JeffFessler]

why would you want to strip out the the unit properties

I was not proposing to strip out any properties. I was proposing to also support unit-less comparisons with 0 and Inf, as a convenience to users. I edited the code above to make some corrections. I also edited the text below the code to clarify the benefit. I am closing the issue because it is only a question of convenience, not a bug and convenience is a matter of preference.

Thanks so much for the pointer to UnitfulRecipes! I did not know about that package and it looks like it will address the issue that brought me here in the first place.

[t-bltg]

Regarding the recent issue in Plots (JuliaPlots/Plots.jl#4366), I'd say that a finite quantity should be comparable to +/- Inf, and would tend towards @JeffFessler 's reasoning and wish to open a PR to fix this.

[cstjean]

On purely math ground, it'd be great to have 5m > 0, since 0m = 0, but consider the expression some_length + some_mass. It could return either a Length, or a Mass, depending on which one of the two is 0. That's type unstable and simply unthinkable for the performance of Unitful.

Besides, I agree with @giordano that while "no apple" and "no elephant" is the same thing, adding "infinitely many apples" and "infinitely many elephants" is nonsensical. You can write Inf * u"m" and it works fine.