change to unwrap_inputs round to 16 decimal places was added

[fcuantico]

Is this pull request associated with an issue(s)?
Yes, based on an error representation I think between python and c++ of the number zero.

Please list issues associated with this pull request, including closing words
as appropriate.

In the communication between python and c++ it looks like the number zero changes from 0.0 to 4.423185485e-315. This was observed for the coordinates of the (0.0, 0.0, 0.0) vector. So instead of the zero vector it was show the vector:

([4.423185485e-315, 4.42424859e-315, 4.41864936e-315 )

Description
Keeps the zero vector as it should by using round to 16 decimal places in:

'
def _compare_mol_and_point(mol, points):
"""This function is essentially a work around for the comparisons not being
exposed to Python.
"""
if mol.size() != points.size():
return False

for i in range(mol.size()):
    atom_i = mol.at(i)
    point_i = points.at(i)

    for j in range(3):
        if round(atom_i.coord(j),16) != round(point_i.coord(j),16):  <--- Here the round function was used
            return False

return True

'

TODOs
I think there is nothing else to do.

[ryanmrichard]

This is NOT defaulting to the original behavior. The original behavior was exact equality.

[fcuantico]

Not sure then what was the first comment about having a conditional, the first time I shared the error, that Is why I change the function and add a conditional for equality if needed.

Don't know what to do from here

[ryanmrichard]

This check can run into problems with floating-point representation of hard-zero. Please use None as the default values for atol and rtol and switch this line to check for None and not 0.0.

[fcuantico]

Same comment as before, not sure if I need to leave it the way it was

[ryanmrichard]

You shouldn't be changing this method. The call to _compare_mol_and_point should always use exact equality. If the user provides even slightly different molecule objects, they are NOT requesting the derivative at the same point.

If this is where your error was originating from (as opposed to you trying to reuse _compare_mol_and_point, which is what I thought the problem was), then I suspect that the problem is that you're not passing the PointSet object from your Molecule object into your module.

[fcuantico]

Same as before not sure if I need to leave it the way it was

[jwaldrop107]

The problem that motivated this PR has been resolved with NWChemEx/Chemist#450. I'm gonna close this now, but it can be reopened and completed if this functionality is still desired.