Fix and tidy coordinate_transform_test

[harrism]

Description

Converting from EXPECT_EQ to expect_vector_equivalent (#669) caused coordinate_transform_test to fail due to floating point differences. It's strange that it passed with exact equality testing (perhaps a problem in Thrust?). In any case, this fixes the test data generation and DRYs up the tests a bit.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[isVoid]

On a second thought:

Philosophically this alters the tests from testing against a golden answer to comparing the result between device compute and host compute. This is acceptable as source of truth only when we are certain that the host computation is correct (which is easy to verify since the kernel of coordinate_transform is very simple.

I think it would be nice in #672 we can discuss a bit about "sources of truth". Pen and paper always works and I think developers should exhaust corner cases with simple inputs first. For larger inputs I would also resort to random generated inputs/existing datasets and computes the result with a mature host counterpart, such as shapely, geopandas, arcgis, postgregis, libgeos etc.

It's also ok to include these in python testing docs too, if you think they fit more over there.

---

It also comes to me what happens if you compare the hardcoded value with the host computed result?

[harrism]

It also comes to me what happens if you compare the hardcoded value with the host computed result?

Indeed, I tested and the host-computed FP32 result does not match the hard-coded FP64 result. So if we want to hard-code expected values we need one per type.

[harrism]

@gpucibot merge