Have strides return nothing on non-strided arrays

[nhz2]

This PR changes strides and stride to return nothing when used on non-strided arrays, instead of throwing an error.

This PR is a continuation of #30432
An alternative is #60964 which adds a new try_strides function instead of changing strides

[adienes]

feels like it should be HasStride ? like HasLength vs length returning nothing

[nhz2]

The issue is that sometimes whether an array is strided or not cannot be determined by the type. Here is an example when combining reshape and view:

A = rand(4, 4)
r1 = reshape(view(A, 1:2, 1:2), 4)
r2 = reshape(view(A, 1:4, 1:2), 8)
typeof(r1) === typeof(r2)
strides(r2)
strides(r1)

[adienes]

still, there really aren't many (any?) APIs in Base like this. the much stronger convention is value-or-error (see also: keys, axes, ndims ...)

[nhz2]

@nanosoldier runtests()

[nhz2]

I wasn't there but this change was already approved by triage in 2022 #30432 (comment)

I'm running pkgeval to see if this change will break any packages.

[adienes]

I think it's worth at least getting fresh eyes on it to confirm, 4 years later. I wasn't there either but to me, this is not a "julian" API.

[nhz2]

Would adding a new try_strides be the more "julian" alternative? The goal is to have some way to quickly tell if an AbstractArray is strided, and if so what its strides are. Currently a lot of performance is being lost when using non Base strided arrays: for example:

julia> using PythonCall

julia> y = ones(1000000);

julia> x = PyArray(copy(y));

julia> @time write(mktemp()[2], y)
  0.002410 seconds (23 allocations: 1.609 KiB)
8000000

julia> @time write(mktemp()[2], x)
  0.023997 seconds (24 allocations: 1.625 KiB)
8000000

julia> strides(y)
(1,)

julia> strides(x)
(1,)

[adienes]

in my (subjective) opinion, yes trystrides or try_strides would be much more idiomatic

[adienes]

or: isstrided(x) might be an idiomatic way to spell a trait operating on values

[nanosoldier]

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

Report summary

❗ Packages that crashed

253 packages crashed on the previous version too.

✖ Packages that failed

20 packages failed only on the current version.

• Package has test failures: 7 packages
• Package tests unexpectedly errored: 3 packages
• Test duration exceeded the time limit: 9 packages
• Test log exceeded the size limit: 1 packages

1054 packages failed on the previous version too.

✔ Packages that passed tests

9 packages passed tests only on the current version.

• Other: 9 packages

5881 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

3696 packages successfully loaded on the previous version too.

➖ Packages that were skipped altogether

898 packages were skipped on the previous version too.

[nhz2]

@nanosoldier runtests(["MethodInspector", "PushVectors", "Metatheory", "MKL", "Revise", "BLISBLAS", "GraphViz", "Oxygen", "SimpleFWA", "DMRGenie", "ParallelKDE", "OrbitPropagationLibrary", "ModelingToolkitInputs", "ControlBarrierFunctions", "CoralBlox", "MinimallyDisruptiveCurves", "Plasm", "EcoNetPostProcessing", "ChargeTransport", "WorldDynamics"])

[nanosoldier]

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

Report summary

✖ Packages that failed

3 packages failed only on the current version.

• Package has test failures: 2 packages
• Package tests unexpectedly errored: 1 packages

4 packages failed on the previous version too.

✔ Packages that passed tests

1 packages passed tests only on the current version.

• Other: 1 packages

10 packages passed tests on the previous version too.

~ Packages that at least loaded

2 packages successfully loaded on the previous version too.

[nhz2]

JuliaLang/LinearAlgebra.jl#1610 should fix the failing tests in pkgeval

[nhz2]

@adienes since this is breaking can this PR and #30432 be closed in favor of #60964 ?

[adienes]

I don't mean to claim any authority on the matter beyond asserting my own opinions, but yes, I think #60964 is a nicer approach