Skip to content

Incomplete tests #301

Open
Open

Description

@asmeurer

This is a tracking issue for tests that are currently incomplete. These are mostly notated in the code by TODO comments, but it's useful to note them all here too. I haven't checked everything throughly so if there is something missing that isn't noted in a comment it might not be listed here.

Note there are also some functions that aren't yet tested at all, but those are covered in separate issues (e.g., #248 #299). I also am not including tests that are currently skipped entirely as flaky (#300).

test_array_object.py

  • test_getitem_masking.py (key.ndim < x.ndim not tested)

test_creation_functions.py

The device keyword is never tested (see below)

test_data_type_functions.py

test_fft.py

test_has_names.py

test_indexing.py

test_inspection_functions.py

Basically none of the inspection APIs are currently tested, beyond the basic signature tests. Note that for many of these functions, we may not even need to use hypothesis. Just a basic test that the function outputs the right thing and a smoke test that the data outputted is correct.

test_linalg.py

(note: values testing here might be hard. Values testing isn't as high priority for functions that already generally work)

  • test_det (no values testing)
  • test_eigh (no values testing)
  • test_eigvalsh (no values testing)
  • test_eig (no values testing)
  • test_eigvals (no values testing)
  • test_inv (no values testing)
  • test_matmul (the @ __matmul__ operator methods are not tested)
  • test_matrix_norm (no values testing)
  • test_qr (no test that Q is orthonormal)
  • test_slogdet (no values testing)
  • test_svdvals (no values testing; no test that it agrees with svd())
  • test_trace (need to update dtype assertion, this should match test_sum)
  • test_vector_norm (no values testing)

Additionally, there are some limitations in the hypothesis strategies used by some of the functions. These should be made more general so that the functions are actually tested on a full gamut of possible inputs:

  • symmetric_matrices (does not generate complex Hermitian matrices
  • positive_definite_matrices (only generates stacks of identity matrices
  • invertable_matrices (only generates stacks of diagonal matrices)

test_manipulation_functions.py

test_operators_and_elementwise_functions.py

test_signatures.py

Several issues tracked in other issues: #256, #171

test_sorting_functions.py

  • test_argsort (no testing of signed zeros or nans)
  • test_sort (no testing of signed zeros or nans)

test_special_cases.py

Many special cases are not tested. This is tracked at #284

test_statistical_functions.py

See also #167

  • test_mean (no values testing)
  • test_std (no values testing)
  • test_var (no values testing)

test_utility_functions.py

  • test_diff (no values testing for n > 1)

OTHER

Activity

  1. ev-br commented on Nov 16, 2024

    @ev-br
    Member

    test_negative (there is a TODO about uints)

    The TODO is # TODO: clarify if uints are acceptable, adjust accordingly and apparently negative(uint) wraps around in at least several libraries:

    In [1]: import torch
    
    In [2]: torch.negative
    Out[2]: <function torch._VariableFunctionsClass.negative>
    
    In [3]: torch.negative(torch.as_tensor(3, dtype=torch.uint8))
    Out[3]: tensor(253, dtype=torch.uint8)
    
    In [4]: import jax.numpy as jnp
    
    In [5]: jnp.negative(jnp.asarray(3, dtype=jnp.uint8))
    Out[5]: Array(253, dtype=uint8)
    
    In [6]: import numpy as np
    
    In [7]: np.negative(np.asarray(3, dtype=np.uint8))
    Out[7]: np.uint8(253)
    
    In [8]: np.__version__
    Out[8]: '2.1.0'
    
    In [9]: import array_api_strict as xp
    
    In [10]: xp.negative(xp.asarray(3, dtype=xp.uint8))
    Out[10]: Array(253, dtype=array_api_strict.uint8)
    
    

    The spec does not seem to fix the behavior for unsigned ints: https://data-apis.org/array-api/latest/API_specification/generated/array_api.negative.html

    So maybe a first action item is to clarify the spec?

  2. asmeurer commented on Nov 18, 2024

    @asmeurer
    MemberAuthor

    That sounds right. I thought I remember this already being addressed in the standard, but I guess it never was. At any rate, it's pretty clear to me that this behavior should be undefined in the standard, because we generally don't require wraparound behavior for integers to be defined. Maybe there is (or should be) something in the standard that just states that generally.

  3. rgommers commented on Feb 4, 2025

    @rgommers
    Member

    Tests for DLPack are fairly high-prio in this list. It would help implementers quite a bit, since some of the logic for new keywords (max_version, dl_device, copy) is a little fiddly.

  4. ogrisel commented on Dec 2, 2025

    @ogrisel

    For the record, I just reported a dlpack spec compliance problem to NumPy, and it was fixed right away (to be part of 2.4).

  5. ev-br commented on Mar 23, 2026

    @ev-br
    Member

    Some minimal dlpack testing: #433

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions