Dimensional any and all reduce with Boolean operations

[mbauman]

and not bitwise ones. Specifically, they are now reductions using these operators:

and_all(x, y) = (x && y)::Bool
or_any(x, y) = (x || y)::Bool
# As a performance optimization, avoid runtime branches:
and_all(x::Bool, y::Bool) = (x & y)::Bool
or_any(x::Bool, y::Bool) = (x | y)::Bool

Fixes half of #45562.

[mbauman]

I split this out from #55628 as it seems slightly more clearly like a bugfix — but do note that it required some changes to doctests! Specifically, any!([0 0], [true true]) is now an error. So I still don't think that it should necessarily be backported.

[mbauman]

preserve and test more of the existing behaviors

[LilithHafner]

Is this line the only intended behavior change of this PR?

[mbauman]

Yes, along with the corresponding change to any(; dims) and any! and all!.

[LilithHafner]

Seems like a good idea to require the arguments to all and any to be Bool arrays (or reductions producing Bools). This makes cases that were previously three quarters broken into uniform errors so @nanosoldier runtests(). Nevertheless the bugfix label seems much more accurate than minor change here.

Does this impact performance?

[mbauman]

Just to detangle all the reductions work here:

• This fix is required to make empty dimensional reductions behave the same as their whole-array counterparts because that PR adds a branch:

  isempty(A) && return fill(mapreduce_empty(f, op, eltype(A)), reduced_indices(A, dims))

  In the case of any and all, that mapreduce_empty needs to return false and true, respectively. That isn't the case when these reductions are implemented using bitwise operators. So that's why this fix is currently incorporated into unify reduce/reducedim empty case behaviors #55628 (where nanosoldier is also currently running).
• This does not fix the problem noted in Bug in function all #45562 where dimensional reductions with bitwise operators get the result array type wrong. Fix that is much more enmeshed with getting initialization correct in the first place — and that's the big WIP: a more principled take on dimensional reduction inits #55318 refactor.
• My overall strategy is to split out the behavior changes like these when they can be easily implemented independently of (and in advance of) that big refactor.

[mbauman]

Does this impact performance?

Yeah, looks like this inhibits SIMD. On this branch right now:

julia> @btime any(x; dims=1) setup=(x=falses(10000,10))
  126.083 μs (3 allocations: 112 bytes)
1×10 BitMatrix:
 0  0  0  0  0  0  0  0  0  0

julia> @eval Base.or_any(x,y) = Bool(Bool(x) | Bool(y))

julia> @btime any(x; dims=1) setup=(x=falses(10000,10))
  37.084 μs (3 allocations: 112 bytes)
1×10 BitMatrix:
 0  0  0  0  0  0  0  0  0  0

julia> @eval Base.or_any(x::Bool,y::Bool) = (x | y)::Bool

julia> @btime any(x; dims=1) setup=(x=falses(10000,10))
  27.458 μs (3 allocations: 112 bytes)
1×10 BitMatrix:
 0  0  0  0  0  0  0  0  0  0

The last matches nightly.

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

Report summary

❗ Packages that crashed

2 packages crashed on the previous version too.

✖ Packages that failed

29 packages failed only on the current version.

• Illegal method overwrites during precompilation: 1 packages
• Package has test failures: 5 packages
• Package tests unexpectedly errored: 1 packages
• Tests became inactive: 1 packages
• Test duration exceeded the time limit: 21 packages

1418 packages failed on the previous version too.

✔ Packages that passed tests

24 packages passed tests only on the current version.

• Other: 24 packages

5259 packages passed tests on the previous version too.

~ Packages that at least loaded

1 packages successfully loaded only on the current version.

• Other: 1 packages

2855 packages successfully loaded on the previous version too.

➖ Packages that were skipped altogether

916 packages were skipped on the previous version too.

[mbauman]

Great, I think this is looking good. All the failures look to be numeric instabilities or timeouts in packages that tend to have numeric instabilities or timeouts... and this should manifest as a very clear new TypeError in places that previously worked (but were buggy) — I don't see that in any of the logs.