Changes between Initial Version and Version 1 of Ticket #16520, comment 6


Ignore:
Timestamp:
Apr 22, 2025, 1:13:32 PM (6 months ago)
Author:
Tom Goddard

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #16520, comment 6

    initial v1  
    11That temporary fix to make the ribbon code past residues ranges as int32 to the C++ is ok.  It doesn't handle the bigger problem introduced by numpy 2 that it will produce int64 numpy arrays when converting lists of Python integers.  And the ChimeraX C++ numpy code does not handle 64-bit integer arrays, only 32-bit.  On Mac and Linux even in numpy 1 this ribbon code passes a list of integers which the C++ converts to an int64 numpy array since the numpy 1 default to was to convert to long integers.  But our C++ code sees that and casts it down to 32-bit integers.  On Windows it instead gives an error because the 64-bit integers are not "long" which is 32-bits on Windows.  The basic trouble is that numpy 1 used C type "long" as the default for making integer arrays while numpy 2 instead went to fixed bit length int64 as the default type (or longlong on Windows).
    22
    3 Our C++ code only uses int32 arrays, never int64.  But I'm a bit uncertain whether the proper fix for numpy 2 is to make it still only use int32 and handle the special Windows situation, or whether it would be better to allow int64 arrays in C++ even though we are not currently using them.  I could see a possibility where we might want to allow int64 arrays.  We handle large volume data (3d arrays) with more than 2**32 grid points, and if we were to need a routine that took an array of integer indices into the flattened array then it would need to be 64-bit integers.  So far we haven't needed that, but maybe in the future it will be desirable.
     3Our C++ code only uses int32 arrays, never int64.  But I'm a bit uncertain whether the proper fix for numpy 2 is to make it still only use int32 and handle the special Windows situation, or whether it would be better to allow int64 arrays in C++ even though we are not currently using them.  I could see a possibility where we might want to allow int64 arrays.  We handle large volume data (3d arrays) with more than 2!**32 grid points, and if we were to need a routine that took an array of integer indices into the flattened array then it would need to be 64-bit integers.  So far we haven't needed that, but maybe in the future it will be desirable.