Add assertion for sparsity pattern equality

[upsj]

This PR adds the GKO_ASSERT_MATRIX_NEAR_SPARSITY test assertion, which first checks if the sparsity patterns of the two input matrices match, and then proceeds like GKO_ASSERT_MATRIX_NEAR

This kind of assertion becomes interesting when we add more kernels that modify the sparsity pattern, like SpGeMM or the ParILUT kernels in general.

[pratikvn]

A few questions:

This assertion basically checks if the sparsity pattern is the same, right ? And disregards the non-zero value themselves as I dont see any checks with the non-zero values in the algorithm unless I missed something.

Why did you change par_ilu and csr to check sparsity pattern instead ? I think the cuda, omp and hip actually do need to be checked for the actual matrix equality (including the values), right ?

[upsj]

This assertion basically checks if the sparsity pattern is the same, right ? And disregards the non-zero value themselves as I dont see any checks with the non-zero values in the algorithm unless I missed something.

If the sparsity patterns are equal, we proceed like in ASSERT_MTX_NEAR by computing the relative error and checking it against the tolerance. The assertion is thus just a stricter version of ASSERT_MTX_NEAR in case we want to make sure that the stored locations are equal as well.

[pratikvn]

Hm, I see. I would prefer if the two things were separate. Comparing the sparsity patterns and the matrix themselves. If need be then you add both the checks. That way it is clear what you want to check.

I think if you have a check sparsity pattern which also does a matrix equality (with a tolerance) check it is a bit misleading. For example, I was initially a bit confused when I saw that the CSR apply tests were checking for sparsity pattern equality.

[upsj]

I see your point, and did not give it too much thought before. Do you have an example in mind where it makes sense to check for pattern equality, but not for value equality?

[pratikvn]

I think there could be a case in some preconditioners where this is possible. But actually that is not my concern because your implementation actually will not have a problem with that as you can always increase the tolerance so that the matrix values become unimportant.

But to me, matrix equality is a stricter check because it should combine both sparsity pattern and value check and hence I think the sparsity pattern check should not need to do any value checks.

[upsj]

I see, that makes sense. I'll separate the two assertion types

[tcojean]

LGTM. But I think you are missing the new assertions for hip/test/matrix/csr_kernels.hip.cpp.

[upsj]

LGTM. But I think you are missing the new assertions for hip/test/matrix/csr_kernels.hip.cpp.

We currently have no HIP implementation of spgemm, so the tests are not present there.

[tcojean]

@upsj My bad, just realizing now what were the tests in question.

[pratikvn]

LGTM!

[thoasm]

LGTM, just a small nit.