Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-9707

Please make assertFloatsAlmostEqual more flexible

    XMLWordPrintable

    Details

      Description

      lsst.utils.assertFloatsAlmostEqual cannot handle lists of floats. Thus it cannot handle values returned from C++ as std::vector. Similarly for tuples of floats, lists of lists of floats, etc., though those may be rarer.

      The usual workaround is to use self.assertTrue(numpy.allclose(arr1, arr2)) but it would be nice not to have to do that.

      Also please consider adding a equal_nan flag like numpy.allclose. In both cases it is worth considering using numpy allclose as the code that performs the test.

        Attachments

          Issue Links

            Activity

            Hide
            Parejkoj John Parejko added a comment -

            Adding a ticket I filed earlier about using np.allclose. Also removed myself as the assignee: I'm not taking responsibility for this code, I just documented its availability!

            Show
            Parejkoj John Parejko added a comment - Adding a ticket I filed earlier about using np.allclose . Also removed myself as the assignee: I'm not taking responsibility for this code, I just documented its availability!
            Hide
            rowen Russell Owen added a comment -

            See afw/tests/test_endpoint.py and test_transform.py for examples where this would be useful.

            Also, I observe that the first argument cannot be a list, but the second argument can be.

            Show
            rowen Russell Owen added a comment - See afw/tests/test_endpoint.py and test_transform.py for examples where this would be useful. Also, I observe that the first argument cannot be a list, but the second argument can be.
            Hide
            rowen Russell Owen added a comment - - edited

            I'm not sure how important this is. The numpy.testing asserts seem to work fine. I would be interested to know why we provide our own assert.

            Show
            rowen Russell Owen added a comment - - edited I'm not sure how important this is. The numpy.testing asserts seem to work fine. I would be interested to know why we provide our own assert.
            Hide
            jbosch Jim Bosch added a comment -

            I don't remember the details, but I added assertClose specifically because assert(numpy.allclose(...)) didn't do what I needed. I believe it was some combination of better diagnostics on failure and maybe some subtlety in defining relative tolerances.

            Show
            jbosch Jim Bosch added a comment - I don't remember the details, but I added assertClose specifically because assert(numpy.allclose(...)) didn't do what I needed. I believe it was some combination of better diagnostics on failure and maybe some subtlety in defining relative tolerances.
            Hide
            Parejkoj John Parejko added a comment -

            See my comment in DM-7276 about the differences in behavior.

            Show
            Parejkoj John Parejko added a comment - See my comment in DM-7276 about the differences in behavior.
            Hide
            Parejkoj John Parejko added a comment -

            Poking this as I was just burned by the not quite complete behaviour on lists of floats. Might be a good one to deal with as a pair coding exercise.

            Show
            Parejkoj John Parejko added a comment - Poking this as I was just burned by the not quite complete behaviour on lists of floats. Might be a good one to deal with as a pair coding exercise.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rowen Russell Owen
              Watchers:
              Jim Bosch, John Parejko, John Swinbank, Russell Owen, Simon Krughoff
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated: