xtensor icon indicating copy to clipboard operation
xtensor copied to clipboard

Systematic testing

Open AntoinePrv opened this issue 2 years ago • 5 comments

Tests typically use the xt::xarray, sometimes xt::xtensor, but it turns there are some subtle differences between all available containers/expressions/views that leads to error when switching one for another.

A few issues have been caught only when reported by users, who then have to wait for another release to get the fix. For instance

  • https://github.com/xtensor-stack/xtensor-r/issues/85
  • https://github.com/xtensor-stack/xtensor-python/issues/286

Tests should be refactor and templated to systematically run with all

  • xt::xtensor_fixed
  • xt::xtensor
  • xt::xarray
  • A view
  • An expression
  • 1D, ND
  • The Python equivalent
  • The R equivalent
  • The Julia equivalent

Since this may generate a lot of tests, we would need to have strategy to not run/compile all of them at the same time (perhaps that would be only in CI, in parallel).

I am unsure if testing with project in other repositories (language bindings) should be done here or there. Depending if the fix needs to be in xtensor or in the other repository, there will always be a case or PR deadlock.

AntoinePrv avatar Feb 22 '23 09:02 AntoinePrv

A way to cover most of the use cases from the bindings is to test:

  • with column-major order
  • with a tensor whose shape is a vector of signed integers

This should catch 99% of the issues. Other issues would be in the downstream projects themselves.

JohanMabille avatar Feb 22 '23 09:02 JohanMabille

I concur. I too have had my annoying small bugs or missing templates:

  • https://github.com/xtensor-stack/xtensor/issues/2643
  • https://github.com/xtensor-stack/xtensor/pull/2569
  • https://github.com/xtensor-stack/xtensor/pull/2561

That is also why I proposed

  • https://github.com/xtensor-stack/xtensor/issues/2511

What I was planning to do is to write a Python module with most of the xtensor's functions with types xtensor_fixed, xtensor, xarray, pytensor, and pyarray and then test every function against NumPy based on random input. That would cover at least part of what you list above. The only reason that I was hesitating is maintainability. How would we ensure that all possible functions are included?

tdegeus avatar Feb 28 '23 16:02 tdegeus

How would we ensure that all possible functions are included?

I'm not sure that we can; but that should not be a blocker. Also I'm not sure we need to tests with pytensor and pyarray (or that means the tests should leave in another repo), as long as we tests on "containers" with similar properties (like the signed int shapes).

JohanMabille avatar Feb 28 '23 16:02 JohanMabille

@JohanMabille remember we also had that pytensor issue due to the fact that the shape was a view on the Python data.

AntoinePrv avatar Mar 01 '23 17:03 AntoinePrv

An initial proposition for the Python binding : https://github.com/xtensor-stack/xtensor-python/pull/288 . It would be great if we can discuss this a bit.

Furthermore:

  • I'm a bit worried about some the timings... It seems that some of NumPy's function might be really quite faster, or there might be some huge blocker with allocation?
  • The test is finding a first bug (that I stared debugging in https://github.com/xtensor-stack/xtensor/pull/2569 )

tdegeus avatar Mar 02 '23 15:03 tdegeus