Avoid calling extrema(...; dims) with empty arrays

[mbauman]

There's a proposed "minor change" to Julia v1.13 that would make extrema([], dims=2) (and other such reductions) an error, akin to how extrema([]) is an error when init is not specified. This package was flagged as having (at least) one such usage here; it errored in PkgEval. See JuliaLang/julia#55628 for more details.

This addresses that first such usage; there may be other places that similarly need to change by either supplying init or skipping the empty case entirely.

[joa-quim]

Thanks for letting me know about this. But I have a doubt on how to handle this. For example in this case, the fix would better be 4 lines above, after the declaration of

dest::Matrix{Float64} = zeros(Float64, DS.n_rows, DS.n_columns + plusZzero)

to add

isempty(dest) && continue       # Skip empty segments

But, and here is my doubt, would this type of solution avoid that nanosoldier would still flag the current case?

[mbauman]

Yeah, that sounds like a great solution that would further simply things here; I'm not familiar with this codebase so I made the most minimal and straightforward change I could easily see.

I do suspect that it'll also happen in those other places I linked; PkgEval errored while precompiling the package so we only tripped over the very first failure.

[joa-quim]

Hmm, wait, I'm a bit confused. You say that extrema([], dims=2) will become an error but all (but one) cases pointed out are doing extrema([], dims=1) and that is already an error. e.g.

extrema(Vector{Float64}(undef, 0), dims=1)
ERROR: ArgumentError: reducing over an empty collection is not allowed

[joa-quim]

OK, the fix needs to be here after all (skipping above would break some code)

[joa-quim]

Try to address all of these cases with #1713

[mbauman]

Thanks for taking this across the line — I know changes like these are annoying, and I appreciate the understanding!