Docstrings are too specific for 32-bit architectures

[lpsinger]

Apparently, on 32-bit architectures, the string representation of Numpy arrays of type int64 changes slightly.

See Debian build log. This is for i386, but the error is similar for all supported 32-bit platforms. Excerpt here:

=================================== FAILURES ===================================
________________________ [doctest] docs/cone_search.rst ________________________
009 resolution HEALPix maps where the number of pixels may become arbitrarily large.
010 
011 Instead, the :meth:`~astropy_healpix.HEALPix.cone_search_lonlat` method can be used to
012 efficiently find all HEALpix pixels within a certain radius from a
013 longitude/latitude::
014 
015     >>> from astropy import units as u
016     >>> from astropy_healpix import HEALPix
017     >>> hp = HEALPix(nside=16, order='nested')
018     >>> hp.cone_search_lonlat(10 * u.deg, 30 * u.deg, radius=10 * u.deg)
Differences (unified diff with -expected +actual):
    @@ -1,3 +1,4 @@
     array([1269,  160,  162, 1271, 1270, 1268, 1246, 1247,  138,  139,  161,
            1245,  136,  137,  140,  142,  130,  131, 1239, 1244, 1238, 1241,
    -       1243, 1265, 1267, 1276, 1273, 1277,  168,  169,  163,  166,  164])
    +       1243, 1265, 1267, 1276, 1273, 1277,  168,  169,  163,  166,  164],
    +      dtype=int64)

/tmp/astropy_healpix-test-7Udyrf/lib/python2.7/site-packages/docs/cone_search.rst:18: DocTestFailure
________________________ [doctest] docs/coordinates.rst ________________________
029     >>> lon.hourangle  # doctest: +FLOAT_CMP
030     array([ 3.1875,  6.25  ,  1.8   ])
031     >>> lat.degree  # doctest: +FLOAT_CMP
032     array([  4.78019185,  54.3409123 , -44.99388015])
033 
034 Conversely, given longitudes and latitudes as :class:`~astropy.units.Quantity`
035 objects, it is possible to recover HEALPix pixel indices::
036 
037     >>> from astropy import units as u
038     >>> hp.lonlat_to_healpix([1, 3, 4] * u.deg, [5, 6, 9] * u.deg)
Expected:
    array([1217, 1217, 1222])
Got:
    array([1217, 1217, 1222], dtype=int64)

/tmp/astropy_healpix-test-7Udyrf/lib/python2.7/site-packages/docs/coordinates.rst:38: DocTestFailure
=============== 2 failed, 248 passed, 2 skipped in 5.63 seconds ================

[cdeil]

Do you think we should support 32-bit?

I think it's a tiny fraction of users, so not supporting it is an option.

If we do want to support it, we should start by adding a CI build to show the error (which as I understand can be done, e.g. Astropy still has this).

[lpsinger]

Do you think we should support 32-bit?

I don't see why not. This seemed to be the only real 32-bit snag.

[lpsinger]

This is the workaround that I used:
https://salsa.debian.org/debian-astro-team/astropy-healpix/blob/master/debian/patches/0002-Fix-docstrings-for-32-bit-architectures.patch

[astrofrog]

The workaround looks good to me - @lpsinger could you do a PR here?

[lpsinger]

I am hoping there is some way to work around this with np.set_printoptions.

[lpsinger]

It might be more user-friendly if we provided ufuncs for both 32 and 64 bit types, because on 32-bit machines np.int64 can't be automatically cast to np.intp and used to index a Numpy array. That would also make this test failure go away.