[cctbxbb] normalize() is not safe

[Oleg Sobolev]

Dear colleagues,

I recently discovered that normalize() function of scitbx::vec3<double> is
not safe, i.e. this case
scitbx::vec3<double> a(0,0,0);
a.normalize();
it will produce division by zero and fail. If function contains this being
called from python the traceback would be rather vague:
<...>
Floating-point error (Python and libc call stacks above)
                This crash may be due to a problem in any imported
                Python module, including modules which are not part
                of the cctbx project. To disable the traps leading
                to this message, define these environment variables
                (e.g. assign the value 1):
                    BOOST_ADAPTBX_FPE_DEFAULT
                    BOOST_ADAPTBX_SIGNALS_DEFAULT
                This will NOT solve the problem, just mask it, but
                may allow you to proceed in case it is not critical.

The code that generates this error sits in scitbx/vec3.h, lines 143-153
with a comment that this was done intentionally and a pointer to an
appropriate function to do safe normalization. This function is not wrapped
to be available in python directly.

Similar functionality (but coded in a different place) accessible via
python by:
>>> from scitbx import matrix
>>> b = matrix.col([0,0,0])
>>> b.normalize()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/net/anaconda/raid1/olegs/phenix_queue/modules/cctbx_project/scitbx/matrix/__init__.py",
line 270, in normalize
    return self / abs(self)
  File
"/net/anaconda/raid1/olegs/phenix_queue/modules/cctbx_project/scitbx/matrix/__init__.py",
line 158, in __truediv__
    return rec([e/other for e in self.elems], self.n)
ZeroDivisionError: float division by zero

Fast grepping shows that normalize() is widely used in xfel, smtbx, rstbx,
dxtbx, mmtbx/hydrogens, scitbx/rigid_body, and in some other places.

My questions to CCTBX community are:
1. Were you aware of this issue?
2. Should we do something about it:
  - make the function more safe and slow;
  - leave it like it is and let everybody know about the issue and let
developers deal with it individually;
3. Any other input on the matter?

Best regards,
Oleg Sobolev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20170501/51d869e7/attachment.htm>