These won't always be exactly equal

https://github.com/ngageoint/sarpy/blob/ec54673e089f972c2b740b00cb45b0651940a735/sarpy/consistency/cphd_consistency.py#L1225

srp comes from the PVP parameters which are double precision floating point.

iarp comes from the XML string representation which has limited significant digits.

There are a few solutions:

• np.around(srp, digits=9)
• print more significant digits in the XML

I lean towards the first one. If someone doesn’t use sarpy to create the CPHD (as I did) this could still fail.

[mtrachy]

I think the most elegant solution is to change https://github.com/ngageoint/sarpy/blob/ec54673e089f972c2b740b00cb45b0651940a735/sarpy/consistency/cphd_consistency.py#L1121 to

            if issubclass(np.asarray(expected_value).dtype.type, numbers.Number):

that way any number or array of numbers is being compared using a con.Approx which uses np.isclose under the hood.

Then the changes to this file from an earlier commit: https://github.com/ngageoint/sarpy/commit/41d2260dc876e682dea77a49ce555ea0ddb48670#diff-40594572e8169b144e447ae57d6c93a6aaf047a43dd46de34a46f592874e9c67

could be rolled back. The change to let atol = 1e-6 should probably be kept.

[mstewart-vsc]

It’s not clear which line is causing the failure, but it’s possible that it is this assert here:

https://github.com/ngageoint/sarpy/blob/ec54673e089f972c2b740b00cb45b0651940a735/sarpy/consistency/cphd_consistency.py#L1126

I believe changing the assert to the following is more appropriate and might fix the problem @klucar is encountering, but I can’t be sure without the problematic test data.

                assert np.allclose(expected_value, actual_value, **approx_args)