Add ispositive, etc.

[putianyi889]

• Can we have definitions like ispositive & isnonnegative? #35067

It's faster for some complicated Real types.

julia> f(x) = x<=zero(typeof(x))
f (generic function with 1 method)

julia> g(x) = signbit(x)||iszero(x)
g (generic function with 1 method)

julia> @btime f(x) setup=(x=rand(BigFloat))
  99.055 ns (4 allocations: 144 bytes)
true

julia> @btime g(x) setup=(x=rand(BigFloat))
  10.700 ns (0 allocations: 0 bytes)
false

If you think this is a good idea then I'll add docstrings and tests.

Edit: FAQs according to discussions below

• Why ispositive(x::Bool) = x?
  • Because it's fast. Add ispositive, etc. #53677 (comment)
• Why support ispositive(::Any)?
  • Can we have definitions like ispositive & isnonnegative? #35067

TODO:

• Edit NEWS.md.
• Add a comment on future change as Suboptimal codegen for Bool assignment #21712 is closed. ref: Add ispositive, etc. #53677 (comment)

[goerz]

For additional context: JuliaRegistries/General#102561

[mikmoore]

I'll just remark on ispositive, but the same goes for isnegative.

Needs NaN handling. For example,

julia> ispositive(NaN) ⊻ ispositive(-NaN)
true

A possible fix is in the flavor of ispositive(x) = !isnan(x) && !signbit(x) && !iszero(x). The default for non-float Number types is isnan(x) = false so this should be compiled away when irrelevant.

Also needs proper Missing behavior, ispositive(::Missing) = missing.

Now for your benchmarks (which appear to implement a "isnonpositive" function that does not appear in this PR, but I'll roll with it for now):

julia> using BenchmarkTools

julia> f(x) = x<=zero(typeof(x));

julia> g(x) = signbit(x)||iszero(x);

julia> g_fixed(x) = !isnan(x)&&(signbit(x)||iszero(x));

julia> h(x) = x <= false;

julia> h_int(x) = x <= 0;

julia> vi32 = rand(Int32,1000); vf64 = randn(Float64,1000); vbf = randn(BigFloat,1000);

julia> @btime count(f,$vi32); @btime count(g,$vi32); @btime count(g_fixed,$vi32); @btime count(h,$vi32); @btime count(h_int,$vi32)
  84.528 ns (0 allocations: 0 bytes)
  84.112 ns (0 allocations: 0 bytes)
  84.495 ns (0 allocations: 0 bytes)
  84.079 ns (0 allocations: 0 bytes)
  82.622 ns (0 allocations: 0 bytes)
517

julia> @btime count(f,$vf64); @btime count(g,$vf64); @btime count(g_fixed,$vf64); @btime count(h,$vf64); @btime count(h_int,$vf64)
  61.914 ns (0 allocations: 0 bytes)
  90.900 ns (0 allocations: 0 bytes)
  134.514 ns (0 allocations: 0 bytes)
  59.470 ns (0 allocations: 0 bytes)
  58.163 ns (0 allocations: 0 bytes)
489

julia> @btime count(f,$vbf);  @btime count(g,$vbf);  @btime count(g_fixed,$vbf);  @btime count(h,$vbf);  @btime count(h_int,$vbf)
  25.100 μs (2000 allocations: 101.56 KiB)
  12.900 μs (0 allocations: 0 bytes)
  14.000 μs (0 allocations: 0 bytes)
  54.900 μs (2000 allocations: 39.06 KiB)
  14.200 μs (0 allocations: 0 bytes)
498

Don't get hung up on differences of a few ns, which are probably benchmarking artifacts. But notice that this function is notably slower for native floats (and much slower when correctly handling NaN). And it doesn't out-do simple comparisons for BigFloat (that avoid creating a new BigFloat).

My preferred implementation would be h, but that implementation is so simple that I wouldn't introduce a function for it. But my benchmarks do show that we're missing good inequality handling for _comparison_(BigFloat, Bool), in that there's no reason h_int should be better than h in that case.

[putianyi889]

I'll just remark on ispositive, but the same goes for isnegative.

Thanks for the investigation! Looks like the problem is more complex than what I've imagined. Are you on the dev version of Julia? My benchmark results are a little different. count(h_int,$vbf) also has 2000 allocations. I'm on v1.10.2.

Anyway, the methods need different implementations for different types. I'm not sure which the fallback should be.

[simonbyrne]

One thought: rather than defining these, would it be better to define a function which returns a Real or Number, say value?

[putianyi889]

One thought: rather than defining these, would it be better to define a function which returns a Real or Number, say value?

How does that help?

[barucden]

Don't forget to add a compatibility note for the added functions (they are likely to be a part of Julia 1.12.0).

[mikmoore]

Would it make more sense for x > 0 (etc) to be the default implementation and the !isnan & !iszero & !signbit to be the specialization for BigFloat and maybe ::BigInt (basically, to swap the IEEEFloat specialization and the ::Any fallback?) As far as I can tell, BigFloat (and maybe ::BigInt) is the only Base type that will be handled better by this function.

I still think that it might be worth exploring faster inequality checks for BigFloat mixed with other types (at least Bool should be easy). It's a little more complicated to implement, but it could make these new functions unnecessary. I don't see these new functions being used especially often. They add a faster alternative to a specific BigFloat operation, but otherwise are equivalent to x -> x>0 etc. BigFloat is already very slow so I don't see this making a big performance difference in real code.

[putianyi889]

As far as I can tell, BigFloat (and maybe ::BigInt) is the only Base type that will be handled better by this function.

I can think of AbstractIrrational (although signbit has not yet been specialized) and Unsigned as well, so basically IEEEFloat is the only group where isnegative(x)=x<0 is strictly better (and SignedBitInteger is on par) and it's because of hardware support.

[giordano]

I think the docstrings need to be added to the manual, no?

[putianyi889]

I think the docstrings need to be added to the manual, no?

Should they be with isless (base.md), isfinite (numbers.md) or signbit (math.md)?

[giordano]

Should they be with isless (base.md), isfinite (numbers.md) or signbit (math.md)?

Having to choose, I'd probably pick isless, seems to be the somewhat closer in spirit.