Question: FITS problem reading binary table with variable length columns I want to read a certain FITS file (), which is part of a Multi-Beam-FITS measurement set () as used by several radio observatories around the world. The file has a binary table extension with variable length columns. Usually this works fine, but this particular example has some columns with a "1PJ(1)" type (and one row only), which seems to lead to problems when reading with Here it appears already, that the content of the record ("(1, 1)"] is smaller than the 'itemsize' (109). In fact, accessing the first two columns works, but all var-length columns raise an error: I checked the file with , which results in zero warnings and errors. Thanks a lot for your help! Multi-dimensional arrays in variable-length array columns of a FITS binary table cause file corruption may create corrupted files when writing a to a file, if that table contains a variable-length array (VLA) column with arrays that have two (or more) dimensions. No warnings or errors are raised while writing, yet the resulting file may be unreadable to . Being able to write any n-dimensional arrays to a VLA column, writing that to a file and then successfully reading the column (round-trip). The resulting file is partially or even completely corrupted. a two-dimensional array and place it on a array with a VLA column with that array a from that column and write it to a file the file back Produces the following error: _ Playing around with it a bit more, I could produce some other weird behaviors. Outputs the following: while the expected result would be: So it seems that everything that doesn't fit in the first dimension is going out of bounds and writing over the next array. This explains why it can also heavily corrupt the file. _ Reading the FITS standard, I get the impression that multi-dimensional VLAs should be possible, so this seems like an unexpected behavior. At the very least, if multi-dimensional VLAs aren't meant to be supported, should be throwing errors. Right now it's simply failing silently. Windows-10-10.0.-SP0 Python 3.9.9 (tags/v3.9.9:, Nov 15 2021, 18:08:50) [MSC v.1929 64 bit (AMD64)] Numpy 1.22.2 pyerfa 2.0.0.1 astropy 5.0.1 Scipy 1.7.1

# The VLA has potentially been updated, so we need to                     # update the array descriptors                     raw_field[:] = 0  # reset                    npts = [len(arr) for arr in self._converted[name]]                    npts = [np.prod(arr.shape) for arr in self._converted[name]]                      raw_field[: len(npts), 0] = npts                     raw_field[1:, 1] = (


Question: [Security] Jquery 3.1.1 is vulnerable to untrusted code execution <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code (see and ) <!-- What did you expect to happen. --Update jquery to the version 3.5 or newer in <!-- What actually happened. --<!-- Was the output confusing or poorly described? --jquery version 3.1.1 is distributed with the latest astropy release <!-- ### Steps to Reproduce <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python --<!--### System Details <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --

"""      jquery_url = _config.ConfigItem(        'https://code.jquery.com/jquery-3.1.1.min.js',        'https://code.jquery.com/jquery-3.6.0.min.js',         'The URL to the jquery library.')      datatables_url = _config.ConfigItem(


Question: [Security] Jquery 3.1.1 is vulnerable to untrusted code execution <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code (see and ) <!-- What did you expect to happen. --Update jquery to the version 3.5 or newer in <!-- What actually happened. --<!-- Was the output confusing or poorly described? --jquery version 3.1.1 is distributed with the latest astropy release <!-- ### Steps to Reproduce <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python --<!--### System Details <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --

@property     def jquery_urls(self):         if self._use_local_files:            return ['file://' + join(EXTERN_JS_DIR, 'jquery-3.1.1.min.js'),            return ['file://' + join(EXTERN_JS_DIR, 'jquery-3.6.0.min.js'),                     'file://' + join(EXTERN_JS_DIR, 'jquery.dataTables.min.js')]         else:             return [conf.jquery_url, conf.datatables_url]


Question: ASCII table output to HTML does not support supplied "formats" <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --When writing out an astropy table to HTML format, the option to the  method seems to be ignored. It does work when writing out to other formats, e.g., rst, CSV, MRT, etc. <!-- What did you expect to happen. --I expect the HTML table output to respect the formatting given by the argument. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --The argument seems to be ignored and the output is not formatted as required. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python from import Table from io import StringIO t = Table([(1.-24, 3.-15), (2, 4)], names=('a', 'b')) tc = t.copy() # copy table with StringIO() as sp: (sp, format="html", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) <html<head<meta charset="utf-8"/<meta content="text/html;charset=UTF-8" http-equiv="Content-type"/</head<body<table<thead<tr<tha</th<thb</th</tr</thead<tr<td1.-24</td<td2</td</tr<tr<td3.-15</td<td4</td</tr</table</body</htmlpython with StringIO() as sp: (sp, format="csv", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) a,b 24e-24,2 23e-15,4 python with StringIO() as sp: (sp, format="", formats={"a": lambda x: f"{x:.2e}"}) print(sp.getvalue()) ======== = a b ======== = 24e-24 2 23e-15 4 ======== = ) around your code snippet. --<!-- If necessary, sanitize your screen output to be pasted so you do not reveal secrets like tokens and passwords. --Outputting a HTML table gives the numbers to the full number of decimal places. Instead, outputting to a CSV table: or, e.g., rsrt: gives the formatting as expected. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --Linux-5.4.0-121-generic-x86_64-with-glibc2.31 Python 3.9.12 (main, Jun 1 2022, 11:38:51) [GCC 7.5.0] Numpy 1.22.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.8.1 Matplotlib 3.5.2

cols = list(table.columns.values())          self.data.header.cols = cols        self.data.cols = cols          if isinstance(self.data.fill_values, tuple):             self.data.fill_values = [self.data.fill_values]          self.data._set_fill_values(cols)        self.data._set_col_formats()          lines = []


Question: TST: failed in pyinstaller (computed error is different depending on the order of the arguments) First failing log (2022-03-13): Last successful log (2022-03-12): Looks like this test was in . Any idea how to fix, or ?

# get integer fraction     day = np.round(sum12)    extra, frac = two_sum(sum12, -day)    frac += extra + err12    # Our fraction can now have gotten >0.5 or <-0.5, which means we would    # loose one bit of precision. So, correct for that.    excess = np.round(frac)    # Calculate remaining fraction. This can have gotten >0.5 or <-0.5, which means    # we would lose one bit of precision. So, correct for that.  Here, we need    # particular care for the case that frac=0.5 and check>0 or frac=-0.5 and check<0,    # since in that case if check is large enough, rounding was done the wrong way.    frac, check = two_sum(sum12 - day, err12)    excess = np.where(frac * np.sign(check) != 0.5, np.round(frac),                      np.round(frac+2*check))     day += excess    extra, frac = two_sum(sum12, -day)    frac += extra + err12    frac = sum12 - day    frac += err12     return day, frac


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

index = [x + 1 for x in reversed(index)]             self._writeln(f' Data differs at {index}:')             report_diff_values(values[0], values[1], fileobj=self._fileobj,                               indent_width=self._indent + 1)                               indent_width=self._indent + 1, rtol=self.rtol,                               atol=self.atol)          if self.diff_total > self.numdiffs:             self._writeln(' ...')


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

for index, values in self.diff_bytes:             self._writeln(f' Data differs at byte {index}:')             report_diff_values(values[0], values[1], fileobj=self._fileobj,                               indent_width=self._indent + 1)                               indent_width=self._indent + 1, rtol=self.rtol,                               atol=self.atol)          self._writeln(' ...')         self._writeln(' {} different bytes found ({:.2%} different).'


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

name, attr = col_attr             self._writeln(f' Column {name} has different {col_attrs[attr]}:')             report_diff_values(vals[0], vals[1], fileobj=self._fileobj,                               indent_width=self._indent + 1)                               indent_width=self._indent + 1, rtol=self.rtol,                               atol=self.atol)          if self.diff_rows:             self._writeln(' Table rows differ:')


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

for indx, values in self.diff_values:             self._writeln(' Column {} data differs in row {}:'.format(*indx))             report_diff_values(values[0], values[1], fileobj=self._fileobj,                               indent_width=self._indent + 1)                               indent_width=self._indent + 1, rtol=self.rtol,                               atol=self.atol)          if self.diff_values and self.numdiffs < self.diff_total:             self._writeln(' ...{} additional difference(s) found.'.format(diff --git a/astropy/utils/diff.py b/astropy/utils/diff.py-- a/astropy/utils/diff.py++ b/astropy/utils/diff.py


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

return a != b  def report_diff_values(a, b, fileobj=sys.stdout, indent_width=0):def report_diff_values(a, b, fileobj=sys.stdout, indent_width=0, rtol=0.0, atol=0.0):     """     Write a diff report between two values to the specified file-like object.


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

indent_width : int         Character column(s) to indent. <ins>    rtol, atol : float        Relative and absolute tolerances as accepted by        :func:`numpy.allclose`.</ins>     Returns     -------     identical : bool


Question: rtol for FITSDiff not working as expected. I have question about the rtol parameter for FITSDiff, when I create a report it appears that the numbers cited as being different are within the given relative tolerance. I couldn't figure out why so I thought this may be a bug, apologies if I'm missing something super obvious here! Here's how to recreate the issue using FITSdiff, I included a zip file containing the two fits file and an example logfile.

indent_width=indent_width + 1)             return False         diff_indices = np.transpose(np.where(a != b))        if (np.issubdtype(a.dtype, np.floating) and            np.issubdtype(b.dtype, np.floating)):            diff_indices = np.transpose(where_not_allclose(a, b, rtol=rtol, atol=atol))        else:            diff_indices = np.transpose(np.where(a != b))         num_diffs = diff_indices.shape[0]          for idx in diff_indices[:3]:             lidx = idx.tolist()            fileobj.write(                fixed_width_indent(f'  at {lidx!r}:\n', indent_width))            fileobj.write(fixed_width_indent(f'  at {lidx!r}:\n', indent_width))             report_diff_values(a[tuple(idx)], b[tuple(idx)], fileobj=fileobj,                               indent_width=indent_width + 1)                               indent_width=indent_width + 1, rtol=rtol, atol=atol)          if num_diffs > 3:             fileobj.write(fixed_width_indent(


Question: Can't convert a list of Astropy tables to a NumPy array of tables I recently stumbled upon where someone likes to convert a list of Tables to a NumPy array. By default, NumPy will convert the Table along the way, resulting in the wrong data structure. Using a specific , however, fails with This error leads directly to the source of , which explicitly checks for any to be not , which will raise the error. The reasoning behind that is clear, as given in the comments below. But I wonder if an exception is reasonable for here, and let that pass through. For a single Table, this may be odd, but not necessarily incorrect. And for a list of Tables, to be converted to an array, this may be helpful.

supported and will raise a ValueError.         """         if dtype is not None:            raise ValueError('Datatype coercion is not allowed')            if np.dtype(dtype) != object:                raise ValueError('Datatype coercion is not allowed')            out = np.array(None, dtype=object)            out[()] = self            return out          # This limitation is because of the following unexpected result that         # should have made a table copy while changing the column names.


Question: Comparing Frame with data and SkyCoord with same data raises exception <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --instances and instances with data are somewhat used interchangebly and I am still not sure after all this time spending with astropy what is preferable when... So it's a bit surprising to me, that comparing a frame with data to a instance with exactly the same data raises an exception: python In [1]: from astropy.coordinates import SkyCoord, ICRS In [2]: frame = ICRS("0d", "0d") In [3]: coord = SkyCoord(frame) In [4]: frame == coord TypeError Traceback (most recent call last) Input In [4], in <cell line: 1() ----1 frame == coord File , in (self, value) 1651 def eq(self, value): 1652 """Equality operator for frame. 1653 1654 This implements strict equality and requires that the frames are 1655 equivalent and that the representation data are exactly equal. 1656 """ -1657 isequiv = self.isequivalentframe(value) 1659 if is None and is None: 1660 # For Frame with no data, == compare is same as isequivalentframe() 1661 return isequiv File , in BaseCoordinateFrame.isequivalentframe(self, other) 1358 return True 1359 elif not isinstance(other, BaseCoordinateFrame): -1360 raise TypeError("Tried to do isequivalentframe on something that " 1361 "isn't a frame") 1362 else: 1363 return False TypeError: Tried to do isequivalentframe on something that isn't a frame <!-- What did you expect to happen. --Compare to true / false depending on data. Exception

This implements strict equality and requires that the frames are         equivalent and that the representation data are exactly equal.         """<ins>        if not isinstance(value, BaseCoordinateFrame):            return NotImplemented</ins>         is_equiv = self.is_equivalent_frame(value)          if self._data is None and value._data is None:


Question: Comparing Frame with data and SkyCoord with same data raises exception <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --instances and instances with data are somewhat used interchangebly and I am still not sure after all this time spending with astropy what is preferable when... So it's a bit surprising to me, that comparing a frame with data to a instance with exactly the same data raises an exception: python In [1]: from astropy.coordinates import SkyCoord, ICRS In [2]: frame = ICRS("0d", "0d") In [3]: coord = SkyCoord(frame) In [4]: frame == coord TypeError Traceback (most recent call last) Input In [4], in <cell line: 1() ----1 frame == coord File , in (self, value) 1651 def eq(self, value): 1652 """Equality operator for frame. 1653 1654 This implements strict equality and requires that the frames are 1655 equivalent and that the representation data are exactly equal. 1656 """ -1657 isequiv = self.isequivalentframe(value) 1659 if is None and is None: 1660 # For Frame with no data, == compare is same as isequivalentframe() 1661 return isequiv File , in BaseCoordinateFrame.isequivalentframe(self, other) 1358 return True 1359 elif not isinstance(other, BaseCoordinateFrame): -1360 raise TypeError("Tried to do isequivalentframe on something that " 1361 "isn't a frame") 1362 else: 1363 return False TypeError: Tried to do isequivalentframe on something that isn't a frame <!-- What did you expect to happen. --Compare to true / false depending on data. Exception

f'{self.replicate_without_data()} vs. '                             f'{value.replicate_without_data()}')         if ((value._data is None and self._data is not None)                or (self._data is None and value._data is not None)):        if (value._data is None) != (self._data is None):             raise ValueError('cannot compare: one frame has data and the other '                              'does not') diff --git a/astropy/coordinates/sky_coordinate.py b/astropy/coordinates/sky_coordinate.py-- a/astropy/coordinates/sky_coordinate.py++ b/astropy/coordinates/sky_coordinate.py


Question: Comparing Frame with data and SkyCoord with same data raises exception <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --instances and instances with data are somewhat used interchangebly and I am still not sure after all this time spending with astropy what is preferable when... So it's a bit surprising to me, that comparing a frame with data to a instance with exactly the same data raises an exception: python In [1]: from astropy.coordinates import SkyCoord, ICRS In [2]: frame = ICRS("0d", "0d") In [3]: coord = SkyCoord(frame) In [4]: frame == coord TypeError Traceback (most recent call last) Input In [4], in <cell line: 1() ----1 frame == coord File , in (self, value) 1651 def eq(self, value): 1652 """Equality operator for frame. 1653 1654 This implements strict equality and requires that the frames are 1655 equivalent and that the representation data are exactly equal. 1656 """ -1657 isequiv = self.isequivalentframe(value) 1659 if is None and is None: 1660 # For Frame with no data, == compare is same as isequivalentframe() 1661 return isequiv File , in BaseCoordinateFrame.isequivalentframe(self, other) 1358 return True 1359 elif not isinstance(other, BaseCoordinateFrame): -1360 raise TypeError("Tried to do isequivalentframe on something that " 1361 "isn't a frame") 1362 else: 1363 return False TypeError: Tried to do isequivalentframe on something that isn't a frame <!-- What did you expect to happen. --Compare to true / false depending on data. Exception

equivalent, extra frame attributes are equivalent, and that the         representation data are exactly equal.         """        if isinstance(value, BaseCoordinateFrame):            if value._data is None:                raise ValueError("Can only compare SkyCoord to Frame with data")            return self.frame == value         if not isinstance(value, SkyCoord):             return NotImplemented         # Make sure that any extra frame attribute names are equivalent.         for attr in self._extra_frameattr_names | value._extra_frameattr_names:             if not self.frame._frameattr_equiv(getattr(self, attr),


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

import numpy as npimport erfa  from astropy.time import Timefrom astropy import units as ufrom .builtin_frames.utils import get_jd12 from .matrix_utilities import rotation_matrix, matrix_product, matrix_transpose   jd1950 = Time('B1950').jd jd2000 = Time('J2000').jd_asecperrad = u.radian.to(u.arcsec)   def eccentricity(jd):


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

Parameters     ----------     jd : scalar or array-like        Julian date at which to compute the obliquity        Julian date (TT) at which to compute the obliquity     algorithm : int        Year of algorithm based on IAU adoption. Can be 2006, 2000 or 1980. The        2006 algorithm is mentioned in Circular 179, but the canonical reference        for the IAU adoption is apparently Hilton et al. 06 is composed of the        1980 algorithm with a precession-rate correction due to the 2000        precession models, and a description of the 1980 algorithm can be found        in the Explanatory Supplement to the Astronomical Almanac.        Year of algorithm based on IAU adoption. Can be 2006, 2000 or 1980.        The IAU 2006 algorithm is based on Hilton et al. 2006.        The IAU 1980 algorithm is based on the Explanatory Supplement to the        Astronomical Almanac (1992).        The IAU 2000 algorithm starts with the IAU 1980 algorithm and applies a        precession-rate correction from the IAU 2000 precession model.      Returns     -------


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

References     ----------    * Hilton, J. et al., 2006, Celest.Mech.Dyn.Astron. 94, 351. 2000    * USNO Circular 179    * Hilton, J. et al., 2006, Celest.Mech.Dyn.Astron. 94, 351    * Capitaine, N., et al., 2003, Astron.Astrophys. 400, 1145-1154     * Explanatory Supplement to the Astronomical Almanac: P. Kenneth       Seidelmann (ed), University Science Books (1992).     """    T = (jd - jd2000) / 36525.0     if algorithm == 2006:        p = (-0.0000000434, -0.000000576, 0.00200340, -0.0001831, -46.836769, 84381.406)        corr = 0        return np.rad2deg(erfa.obl06(jd, 0))     elif algorithm == 2000:        p = (0.001813, -0.00059, -46.8150, 84381.448)        corr = -0.02524 * T        return np.rad2deg(erfa.obl80(jd, 0) + erfa.pr00(jd, 0)[1])     elif algorithm == 1980:        p = (0.001813, -0.00059, -46.8150, 84381.448)        corr = 0        return np.rad2deg(erfa.obl80(jd, 0))     else:         raise ValueError('invalid algorithm year for computing obliquity')     return (np.polyval(p, T) + corr) / 3600. # TODO: replace this with SOFA equivalent def precession_matrix_Capitaine(fromepoch, toepoch):     """    Computes the precession matrix from one Julian epoch to another.    The exact method is based on Capitaine et al. 2003, which should    match the IAU 2006 standard.    Computes the precession matrix from one Julian epoch to another, per IAU 2006.      Parameters     ----------


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

References     ----------    USNO Circular 179    Hilton, J. et al., 2006, Celest.Mech.Dyn.Astron. 94, 351     """    mat_fromto2000 = matrix_transpose(        _precess_from_J2000_Capitaine(fromepoch.jyear))    mat_2000toto = _precess_from_J2000_Capitaine(toepoch.jyear)    return np.dot(mat_2000toto, mat_fromto2000)def _precess_from_J2000_Capitaine(epoch):    """    Computes the precession matrix from J2000 to the given Julian Epoch.    Expression from from Capitaine et al. 2003 as expressed in the USNO    Circular 179.  This should match the IAU 2006 standard from SOFA.    Parameters    ----------    epoch : scalar        The epoch as a Julian year number (e.g. J2000 is 2000.0)    """    T = (epoch - 2000.0) / 100.0    # from USNO circular    pzeta = (-0.0000003173, -0.000005971, 0.01801828, 0.2988499, 2306.083227, 2.650545)    pz = (-0.0000002904, -0.000028596, 0.01826837, 1.0927348, 2306.077181, -2.650545)    ptheta = (-0.0000001274, -0.000007089, -0.04182264, -0.4294934, 2004.191903, 0)    zeta = np.polyval(pzeta, T) / 3600.0    z = np.polyval(pz, T) / 3600.0    theta = np.polyval(ptheta, T) / 3600.0    return matrix_product(rotation_matrix(-z, 'z'),                          rotation_matrix(theta, 'y'),                          rotation_matrix(-zeta, 'z'))    # Multiply the two precession matrices (without frame bias) through J2000.0    fromepoch_to_J2000 = matrix_transpose(erfa.bp06(*get_jd12(fromepoch, 'tt'))[1])    J2000_to_toepoch = erfa.bp06(*get_jd12(toepoch, 'tt'))[1]    return J2000_to_toepoch @ fromepoch_to_J2000   def _precession_matrix_besselian(epoch1, epoch2):


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

rotation_matrix(-zeta, 'z'))  <del>def _load_nutation_data(datastr, seriestype):    """    Loads nutation series from data stored in string form.    Seriestype can be 'lunisolar' or 'planetary'    """    if seriestype == 'lunisolar':        dtypes = [('nl', int),                  ('nlp', int),                  ('nF', int),                  ('nD', int),                  ('nOm', int),                  ('ps', float),                  ('pst', float),                  ('pc', float),                  ('ec', float),                  ('ect', float),                  ('es', float)]    elif seriestype == 'planetary':        dtypes = [('nl', int),                  ('nF', int),                  ('nD', int),                  ('nOm', int),                  ('nme', int),                  ('nve', int),                  ('nea', int),                  ('nma', int),                  ('nju', int),                  ('nsa', int),                  ('nur', int),                  ('nne', int),                  ('npa', int),                  ('sp', int),                  ('cp', int),                  ('se', int),                  ('ce', int)]    else:        raise ValueError('requested invalid nutation series type')    lines = [l for l in datastr.split('\n')             if not l.startswith('#') if not l.strip() == '']    lists = [[] for _ in dtypes]    for l in lines:        for i, e in enumerate(l.split(' ')):            lists[i].append(dtypes[i][1](e))    return np.rec.fromarrays(lists, names=[e[0] for e in dtypes])_nut_data_00b = """#l lprime F D Omega longitude_sin longitude_sin*t longitude_cos obliquity_cos obliquity_cos*t,obliquity_sin0 0 0 0 1 -172064161.0 -174666.0 33386.0 92052331.0 9086.0 15377.00 0 2 -2 2 -13170906.0 -1675.0 -13696.0 5730336.0 -3015.0 -4587.00 0 2 0 2 -2276413.0 -234.0 2796.0 978459.0 -485.0 1374.00 0 0 0 2 2074554.0 207.0 -698.0 -897492.0 470.0 -291.00 1 0 0 0 1475877.0 -3633.0 11817.0 73871.0 -184.0 -1924.00 1 2 -2 2 -516821.0 1226.0 -524.0 224386.0 -677.0 -174.01 0 0 0 0 711159.0 73.0 -872.0 -6750.0 0.0 358.00 0 2 0 1 -387298.0 -367.0 380.0 200728.0 18.0 318.01 0 2 0 2 -301461.0 -36.0 816.0 129025.0 -63.0 367.00 -1 2 -2 2 215829.0 -494.0 111.0 -95929.0 299.0 132.00 0 2 -2 1 128227.0 137.0 181.0 -68982.0 -9.0 39.0-1 0 2 0 2 123457.0 11.0 19.0 -53311.0 32.0 -4.0-1 0 0 2 0 156994.0 10.0 -168.0 -1235.0 0.0 82.01 0 0 0 1 63110.0 63.0 27.0 -33228.0 0.0 -9.0-1 0 0 0 1 -57976.0 -63.0 -189.0 31429.0 0.0 -75.0-1 0 2 2 2 -59641.0 -11.0 149.0 25543.0 -11.0 66.01 0 2 0 1 -51613.0 -42.0 129.0 26366.0 0.0 78.0-2 0 2 0 1 45893.0 50.0 31.0 -24236.0 -10.0 20.00 0 0 2 0 63384.0 11.0 -150.0 -1220.0 0.0 29.00 0 2 2 2 -38571.0 -1.0 158.0 16452.0 -11.0 68.00 -2 2 -2 2 32481.0 0.0 0.0 -13870.0 0.0 0.0-2 0 0 2 0 -47722.0 0.0 -18.0 477.0 0.0 -25.02 0 2 0 2 -31046.0 -1.0 131.0 13238.0 -11.0 59.01 0 2 -2 2 28593.0 0.0 -1.0 -12338.0 10.0 -3.0-1 0 2 0 1 20441.0 21.0 10.0 -10758.0 0.0 -3.02 0 0 0 0 29243.0 0.0 -74.0 -609.0 0.0 13.00 0 2 0 0 25887.0 0.0 -66.0 -550.0 0.0 11.00 1 0 0 1 -14053.0 -25.0 79.0 8551.0 -2.0 -45.0-1 0 0 2 1 15164.0 10.0 11.0 -8001.0 0.0 -1.00 2 2 -2 2 -15794.0 72.0 -16.0 6850.0 -42.0 -5.00 0 -2 2 0 21783.0 0.0 13.0 -167.0 0.0 13.01 0 0 -2 1 -12873.0 -10.0 -37.0 6953.0 0.0 -14.00 -1 0 0 1 -12654.0 11.0 63.0 6415.0 0.0 26.0-1 0 2 2 1 -10204.0 0.0 25.0 5222.0 0.0 15.00 2 0 0 0 16707.0 -85.0 -10.0 168.0 -1.0 10.01 0 2 2 2 -7691.0 0.0 44.0 3268.0 0.0 19.0-2 0 2 0 0 -11024.0 0.0 -14.0 104.0 0.0 2.00 1 2 0 2 7566.0 -21.0 -11.0 -3250.0 0.0 -5.00 0 2 2 1 -6637.0 -11.0 25.0 3353.0 0.0 14.00 -1 2 0 2 -7141.0 21.0 8.0 3070.0 0.0 4.00 0 0 2 1 -6302.0 -11.0 2.0 3272.0 0.0 4.01 0 2 -2 1 5800.0 10.0 2.0 -3045.0 0.0 -1.02 0 2 -2 2 6443.0 0.0 -7.0 -2768.0 0.0 -4.0-2 0 0 2 1 -5774.0 -11.0 -15.0 3041.0 0.0 -5.02 0 2 0 1 -5350.0 0.0 21.0 2695.0 0.0 12.00 -1 2 -2 1 -4752.0 -11.0 -3.0 2719.0 0.0 -3.00 0 0 -2 1 -4940.0 -11.0 -21.0 2720.0 0.0 -9.0-1 -1 0 2 0 7350.0 0.0 -8.0 -51.0 0.0 4.02 0 0 -2 1 4065.0 0.0 6.0 -2206.0 0.0 1.01 0 0 2 0 6579.0 0.0 -24.0 -199.0 0.0 2.00 1 2 -2 1 3579.0 0.0 5.0 -1900.0 0.0 1.01 -1 0 0 0 4725.0 0.0 -6.0 -41.0 0.0 3.0-2 0 2 0 2 -3075.0 0.0 -2.0 1313.0 0.0 -1.03 0 2 0 2 -2904.0 0.0 15.0 1233.0 0.0 7.00 -1 0 2 0 4348.0 0.0 -10.0 -81.0 0.0 2.01 -1 2 0 2 -2878.0 0.0 8.0 1232.0 0.0 4.00 0 0 1 0 -4230.0 0.0 5.0 -20.0 0.0 -2.0-1 -1 2 2 2 -2819.0 0.0 7.0 1207.0 0.0 3.0-1 0 2 0 0 -4056.0 0.0 5.0 40.0 0.0 -2.00 -1 2 2 2 -2647.0 0.0 11.0 1129.0 0.0 5.0-2 0 0 0 1 -2294.0 0.0 -10.0 1266.0 0.0 -4.01 1 2 0 2 2481.0 0.0 -7.0 -1062.0 0.0 -3.02 0 0 0 1 2179.0 0.0 -2.0 -1129.0 0.0 -2.0-1 1 0 1 0 3276.0 0.0 1.0 -9.0 0.0 0.01 1 0 0 0 -3389.0 0.0 5.0 35.0 0.0 -2.01 0 2 0 0 3339.0 0.0 -13.0 -107.0 0.0 1.0-1 0 2 -2 1 -1987.0 0.0 -6.0 1073.0 0.0 -2.01 0 0 0 2 -1981.0 0.0 0.0 854.0 0.0 0.0-1 0 0 1 0 4026.0 0.0 -353.0 -553.0 0.0 -139.00 0 2 1 2 1660.0 0.0 -5.0 -710.0 0.0 -2.0-1 0 2 4 2 -1521.0 0.0 9.0 647.0 0.0 4.0-1 1 0 1 1 1314.0 0.0 0.0 -700.0 0.0 0.00 -2 2 -2 1 -1283.0 0.0 0.0 672.0 0.0 0.01 0 2 2 1 -1331.0 0.0 8.0 663.0 0.0 4.0-2 0 2 2 2 1383.0 0.0 -2.0 -594.0 0.0 -2.0-1 0 0 0 2 1405.0 0.0 4.0 -610.0 0.0 2.01 1 2 -2 2 1290.0 0.0 0.0 -556.0 0.0 0.0"""[1:-1]_nut_data_00b = _load_nutation_data(_nut_data_00b, 'lunisolar')# TODO: replace w/SOFA equivalent</del> def nutation_components2000B(jd):     """     Computes nutation components following the IAU 2000B specification


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

Parameters     ----------     jd : scalar        epoch at which to compute the nutation components as a JD        Julian date (TT) at which to compute the nutation components      Returns     -------


Question: Problem in function nutationmatrix in Recently, when I try to call function nutationmatrix in astropy.coordinates.earthorientation, error occurs with following info: Angle instances require units equivalent to 'rad', so cannot set it to '0'. Then, I checked the code of def nutationmatrix as follows: In its return sentence, the third argument of 'rotationmatrix' should be , rather than False. Any response?

deps : float         depsilon in raidans     """    epsa = np.radians(obliquity(jd, 2000))    t = (jd - jd2000) / 36525    # Fundamental (Delaunay) arguments from Simon et al. (1994) via SOFA    # Mean anomaly of moon    el = ((485868.249036 + 1717915923.2178 * t) % 1296000) / _asecperrad    # Mean anomaly of sun    elp = ((1287104.79305 + 129596581.0481 * t) % 1296000) / _asecperrad    # Mean argument of the latitude of Moon    F = ((335779.526232 + 1739527262.8478 * t) % 1296000) / _asecperrad    # Mean elongation of the Moon from Sun    D = ((1072260.70369 + 1602961601.2090 * t) % 1296000) / _asecperrad    # Mean longitude of the ascending node of Moon    Om = ((450160.398036 + -6962890.5431 * t) % 1296000) / _asecperrad    # compute nutation series using array loaded from data directory    dat = _nut_data_00b    arg = dat.nl * el + dat.nlp * elp + dat.nF * F + dat.nD * D + dat.nOm * Om    sarg = np.sin(arg)    carg = np.cos(arg)    p1u_asecperrad = _asecperrad * 1e7  # 0.1 microasrcsecperrad    dpsils = np.sum((dat.ps + dat.pst * t) * sarg + dat.pc * carg) / p1u_asecperrad    depsls = np.sum((dat.ec + dat.ect * t) * carg + dat.es * sarg) / p1u_asecperrad    # fixed offset in place of planetary tersm    m_asecperrad = _asecperrad * 1e3  # milliarcsec per rad    dpsipl = -0.135 / m_asecperrad    depspl = 0.388 / m_asecperrad    return epsa, dpsils + dpsipl, depsls + depspl  # all in radians    dpsi, deps, epsa, _, _, _, _, _ = erfa.pn00b(jd, 0)    return epsa, dpsi, deps   def nutation_matrix(epoch):     """    Nutation matrix generated from nutation components.    Nutation matrix generated from nutation components, IAU 2000B model.      Matrix converts from mean coordinate to true coordinate as     r_true = M * r_mean    Parameters    ----------    epoch : `~astropy.time.Time`        The epoch at which to compute the nutation matrix    Returns    -------    nmatrix : 3x3 array        Nutation matrix for the specified epoch    References    ----------    * Explanatory Supplement to the Astronomical Almanac: P. Kenneth      Seidelmann (ed), University Science Books (1992).     """     # TODO: implement higher precision 2006/2000A model if requested/needed    epsa, dpsi, deps = nutation_components2000B(epoch.jd)  # all in radians    return matrix_product(rotation_matrix(-(epsa + deps), 'x', False),                          rotation_matrix(-dpsi, 'z', False),                          rotation_matrix(epsa, 'x', False))    return erfa.num00b(*get_jd12(epoch, 'tt'))


Question: Inconsistent behavior of in <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --I have a 3D WCS with dimensions corresponding to space, space, and wavelength and what some might call a non-trivial PCij matrix that couples the spectral and spatial dimensions. I find that when I perform a worldtopixel on the full (unsliced) WCS, I get back the expected result. However, when I perform that same worldtopixel operation on a single wavelength slice (i.e. a 2D slice with dimensions corresponding to space, space), my worldtopixel returns an erroneous result for one of the dimensions. This issue was originally posted as sunpy/ndcube, but I've moved it here as it seems to be an issue with rather than anything specific to . <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import numpy as np import from astropy.coordinates import SkyCoord import as u nx = 100 ny = 25 nz = 2 wcsheader = { 'WCSAXES': 3, 'CRPIX1': (nx + 1)/2, 'CRPIX2': (ny + 1)/2, 'CRPIX3': 1.0, 'PC11': 0.0, 'PC12': -1.0, 'PC13': 0.0, 'PC21': 1.0, 'PC22': 0.0, 'PC23': -1.0, 'CDELT1': 5, 'CDELT2': 5, 'CDELT3': 0.055, 'CUNIT1': 'arcsec', 'CUNIT2': 'arcsec', 'CUNIT3': 'Angstrom', 'CTYPE1': 'HPLN-TAN', 'CTYPE2': 'HPLT-TAN', 'CTYPE3': 'WAVE', 'CRVAL1': 0.0, 'CRVAL2': 0.0, 'CRVAL3': 1.05, } fitswcs = (header=wcsheader) python pt = SkyCoord(, , (fitswcs)) fitswcs.worldtopixel(pt, 1.05u.angstrom) (array(49.5), array(12.), array(2.-15)) python llslicedwcs = (fitswcs, 0) hlslicedwcs = (llslicedwcs) hlslicedwcs.worldtopixel(pt) (array(1.+11), array(12.)) python px,py,pz = fitswcs.worldtopixel(pt, 1.05u.Angstrom) fitswcs.pixeltoworld(px, py, pz) [<SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.), <SpectralCoord 1.05e-10 m] hlslicedwcs.pixeltoworld(px, py) <SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.)macOS-10.16-x8664-i386-64bit Python 3.9.7 (default, Sep 16 2021, 08:50:36) [Clang 10.0.0 ] Numpy 1.21.5 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.8.0 Matplotlib 3.5.1

return world_arrays      def world_to_pixel_values(self, *world_arrays):<ins>        sliced_out_world_coords = self._pixel_to_world_values_all(*[0]*len(self._pixel_keep))</ins>         world_arrays = tuple(map(np.asanyarray, world_arrays))         world_arrays_new = []         iworld_curr = -1


Question: Inconsistent behavior of in <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --I have a 3D WCS with dimensions corresponding to space, space, and wavelength and what some might call a non-trivial PCij matrix that couples the spectral and spatial dimensions. I find that when I perform a worldtopixel on the full (unsliced) WCS, I get back the expected result. However, when I perform that same worldtopixel operation on a single wavelength slice (i.e. a 2D slice with dimensions corresponding to space, space), my worldtopixel returns an erroneous result for one of the dimensions. This issue was originally posted as sunpy/ndcube, but I've moved it here as it seems to be an issue with rather than anything specific to . <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import numpy as np import from astropy.coordinates import SkyCoord import as u nx = 100 ny = 25 nz = 2 wcsheader = { 'WCSAXES': 3, 'CRPIX1': (nx + 1)/2, 'CRPIX2': (ny + 1)/2, 'CRPIX3': 1.0, 'PC11': 0.0, 'PC12': -1.0, 'PC13': 0.0, 'PC21': 1.0, 'PC22': 0.0, 'PC23': -1.0, 'CDELT1': 5, 'CDELT2': 5, 'CDELT3': 0.055, 'CUNIT1': 'arcsec', 'CUNIT2': 'arcsec', 'CUNIT3': 'Angstrom', 'CTYPE1': 'HPLN-TAN', 'CTYPE2': 'HPLT-TAN', 'CTYPE3': 'WAVE', 'CRVAL1': 0.0, 'CRVAL2': 0.0, 'CRVAL3': 1.05, } fitswcs = (header=wcsheader) python pt = SkyCoord(, , (fitswcs)) fitswcs.worldtopixel(pt, 1.05u.angstrom) (array(49.5), array(12.), array(2.-15)) python llslicedwcs = (fitswcs, 0) hlslicedwcs = (llslicedwcs) hlslicedwcs.worldtopixel(pt) (array(1.+11), array(12.)) python px,py,pz = fitswcs.worldtopixel(pt, 1.05u.Angstrom) fitswcs.pixeltoworld(px, py, pz) [<SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.), <SpectralCoord 1.05e-10 m] hlslicedwcs.pixeltoworld(px, py) <SkyCoord (Helioprojective: obstime=None, rsun=.0 km, observer=None): (Tx, Ty) in arcsec (1.-27, 0.)macOS-10.16-x8664-i386-64bit Python 3.9.7 (default, Sep 16 2021, 08:50:36) [Clang 10.0.0 ] Numpy 1.21.5 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.8.0 Matplotlib 3.5.1

iworld_curr += 1                 world_arrays_new.append(world_arrays[iworld_curr])             else:                world_arrays_new.append(1.)                world_arrays_new.append(sliced_out_world_coords[iworld])          world_arrays_new = np.broadcast_arrays(*world_arrays_new)         pixel_arrays = list(self._wcs.world_to_pixel_values(*world_arrays_new))


Question: throws exception with <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --The decorator throws a when used on a function that returns a with and a return type annotation. <!-- What did you expect to happen. --For the function to return a with with the appropriate units or to throw an exception if the output units are of the wrong type. <!-- What actually happened. --<!-- Was the output confusing or poorly described? --Using the decorator results in a gives <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --

try:             other = Unit(other, parse_strict='silent')         except UnitTypeError:            return NotImplemented            return NotImplemented  # try other.__rlshift__(self)          try:             factor = self.unit._to(other)        except Exception:            # Maybe via equivalencies?  Now we do make a temporary copy.            try:                value = self._to_value(other)            except UnitConversionError:                return NotImplemented            self.view(np.ndarray)[...] = value        except UnitConversionError:  # incompatible, or requires an Equivalency            return NotImplemented        except AttributeError:  # StructuredUnit does not have `_to`            # In principle, in-place might be possible.            return NotImplemented         else:            self.view(np.ndarray)[...] *= factor        view = self.view(np.ndarray)        try:            view *= factor  # operates on view        except TypeError:            # The error is `numpy.core._exceptions._UFuncOutputCastingError`,            # which inherits from `TypeError`.            return NotImplemented          self._set_unit(other)         return self


Question: wcslint crashes on valid WCS calls an underlying function here: Looks like all it does is tries to create a object with the header and report warnings, so the bug is either inside or it is a matter of updating on how validator calls in more complicated cases: File: File: File: (Reported by

"always", FITSFixedWarning, append=True)                  try:                    WCS(hdu.header,                    WCS(hdu.header, hdulist,                         key=wcs.wcs.alt or ' ',                         relax=_wcs.WCSHDR_reject,                         fix=True, _do_set=False)


Question: parses fractional days in year-month-day format incorrectly results in : the fractional days are interpreted as fractional seconds ( is what I hoped for). The format is perhaps not the best format, but it is used, and since Astropy does not raise an exception, but silently returns an incorrect result, this may lead to errors. The issue can be traced to , which will interpret anything right of the last dot as a fractional second. Since matching to regexes or formats is done afterwards, there is no (easy) way to catch this through a subformat before the fractional second get stripped. I'd be happy to try and put in a PR for this (if it's indeed a bug), but I'll need to know whether to raise an exception, or implement a proper parser for this format (provided it doesn't clash with other interpretations). Some suggestions on the best way to attack this issue (or at what point in the code) are welcome as well.

try:             idot = timestr.rindex('.')         except Exception:            fracsec = 0.0            timestr_has_fractional_digits = False         else:             timestr, fracsec = timestr[:idot], timestr[idot:]             fracsec = float(fracsec)            timestr_has_fractional_digits = True          for _, strptime_fmt_or_regex, _ in subfmts:             if isinstance(strptime_fmt_or_regex, str):                subfmt_has_sec = '%S' in strptime_fmt_or_regex                 try:                     tm = time.strptime(timestr, strptime_fmt_or_regex)                 except ValueError:


Question: parses fractional days in year-month-day format incorrectly results in : the fractional days are interpreted as fractional seconds ( is what I hoped for). The format is perhaps not the best format, but it is used, and since Astropy does not raise an exception, but silently returns an incorrect result, this may lead to errors. The issue can be traced to , which will interpret anything right of the last dot as a fractional second. Since matching to regexes or formats is done afterwards, there is no (easy) way to catch this through a subformat before the fractional second get stripped. I'd be happy to try and put in a PR for this (if it's indeed a bug), but I'll need to know whether to raise an exception, or implement a proper parser for this format (provided it doesn't clash with other interpretations). Some suggestions on the best way to attack this issue (or at what point in the code) are welcome as well.

tm = tm.groupdict()                 vals = [int(tm.get(component, default)) for component, default                         in zip(components, defaults)]                subfmt_has_sec = 'sec' in tm            # Add fractional seconds if they were in the original time string            # and the subformat has seconds. A time like "2022-08-01.123" will            # never pass this for a format like ISO and will raise a parsing            # exception.            if timestr_has_fractional_digits:                if subfmt_has_sec:                    vals[-1] = vals[-1] + fracsec                else:                    continue             # Add fractional seconds            vals[-1] = vals[-1] + fracsec             return vals         else:             raise ValueError(f'Time {timestr} does not match {self.name} format')


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

List of table lines          """<ins>        header_rows = getattr(self, "header_rows", ["name"])</ins>          # See "else" clause below for explanation of start_line and position_line         start_line = core._get_line_index(self.start_line, self.process_lines(lines))


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

vals, self.col_starts, col_ends = self.get_fixedwidth_params(line)                 self.col_ends = [x - 1 if x is not None else None for x in col_ends]             # Get the header column names and column positions            line = self.get_line(lines, start_line)            vals, starts, ends = self.get_fixedwidth_params(line)            self.names = vals            # Get the column names from the header line            line = self.get_line(lines, start_line + header_rows.index("name"))            self.names, starts, ends = self.get_fixedwidth_params(line)          self._set_cols_from_names()         for ii, attr in enumerate(header_rows):            if attr != "name":                line = self.get_line(lines, start_line + ii)                vals = self.get_fixedwidth_params(line)[0]                for col, val in zip(self.cols, vals):                    if val:                        setattr(col, attr, val)         # Set column start and end positions.         for i, col in enumerate(self.cols):             col.start = starts[i]


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

"""     splitter_class = FixedWidthSplitter     """ Splitter class for splitting data lines into columns """    start_line = None      def write(self, lines):        default_header_rows = [] if self.header.start_line is None else ['name']        header_rows = getattr(self, "header_rows", default_header_rows)        # First part is getting the widths of each column.        # List (rows) of list (column values) for data lines         vals_list = []         col_str_iters = self.str_vals()         for vals in zip(*col_str_iters):             vals_list.append(vals)         for i, col in enumerate(self.cols):            col.width = max(len(vals[i]) for vals in vals_list)            if self.header.start_line is not None:                col.width = max(col.width, len(col.info.name))        widths = [col.width for col in self.cols]        if self.header.start_line is not None:            lines.append(self.splitter.join([col.info.name for col in self.cols],                                            widths))        # List (rows) of list (columns values) for header lines.        hdrs_list = []        for col_attr in header_rows:            vals = [                "" if (val := getattr(col.info, col_attr)) is None else str(val)                for col in self.cols            ]            hdrs_list.append(vals)        # Widths for data columns        widths = [max(len(vals[i_col]) for vals in vals_list)                  for i_col in range(len(self.cols))]        # Incorporate widths for header columns (if there are any)        if hdrs_list:            for i_col in range(len(self.cols)):                widths[i_col] = max(                    widths[i_col],                    max(len(vals[i_col]) for vals in hdrs_list)                )        # Now collect formatted header and data lines into the output lines        for vals in hdrs_list:            lines.append(self.splitter.join(vals, widths))          if self.header.position_line is not None:            char = self.header.position_char            if len(char) != 1:                raise ValueError(f'Position_char="{char}" must be a single character')            vals = [char * col.width for col in self.cols]            vals = [self.header.position_char * width for width in widths]             lines.append(self.splitter.join(vals, widths))          for vals in vals_list:


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

header_class = FixedWidthHeader     data_class = FixedWidthData     def __init__(self, col_starts=None, col_ends=None, delimiter_pad=' ', bookend=True):    def __init__(        self,        col_starts=None,        col_ends=None,        delimiter_pad=' ',        bookend=True,        header_rows=None    ):        if header_rows is None:            header_rows = ["name"]         super().__init__()         self.data.splitter.delimiter_pad = delimiter_pad         self.data.splitter.bookend = bookend         self.header.col_starts = col_starts         self.header.col_ends = col_ends        self.header.header_rows = header_rows        self.data.header_rows = header_rows        if self.data.start_line is None:            self.data.start_line = len(header_rows)   class FixedWidthNoHeaderHeader(FixedWidthHeader):


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

def __init__(self, col_starts=None, col_ends=None, delimiter_pad=' ', bookend=True):         super().__init__(col_starts, col_ends, delimiter_pad=delimiter_pad,                         bookend=bookend)                         bookend=bookend, header_rows=[])   class FixedWidthTwoLineHeader(FixedWidthHeader):


Question: Add option to input/output column units for fixed width tables Extend the reader to include a keyword arg that will specify that there is a row of unit specifiers after the column name specifiers (or at the top of the header if there are no column names). This will apply for both reading and writing fixed width tables. This allows for outputting a table to a file in a format like with , and then reading back that table with no information loss.

data_class = FixedWidthTwoLineData     header_class = FixedWidthTwoLineHeader     def __init__(self, position_line=1, position_char='-', delimiter_pad=None, bookend=False):        super().__init__(delimiter_pad=delimiter_pad, bookend=bookend)    def __init__(        self,        position_line=None,        position_char='-',        delimiter_pad=None,        bookend=False,        header_rows=None    ):        if len(position_char) != 1:            raise ValueError(                f'Position_char="{position_char}" must be a ''single character'            )        super().__init__(delimiter_pad=delimiter_pad, bookend=bookend,                         header_rows=header_rows)        if position_line is None:            position_line = len(self.header.header_rows)         self.header.position_line = position_line         self.header.position_char = position_char         self.data.start_line = position_line + 1


Question: float32 representation of pi/2 is rejected by <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --The closest float32 value to pi/2 is by accident slightly larger than pi/2: Astropy checks using float64 precision, rejecting "valid" alt values (e.g. float32 values read from files): Be lenient? E.g. only make the comparison up to float 32 precision? See error above See snippet above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --

if angles.unit is u.deg:             limit = 90         elif angles.unit is u.rad:            limit = 0.5 * np.pi            limit = self.dtype.type(0.5 * np.pi)         else:             limit = u.degree.to(angles.unit, 90.0)


Question: float32 representation of pi/2 is rejected by <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --The closest float32 value to pi/2 is by accident slightly larger than pi/2: Astropy checks using float64 precision, rejecting "valid" alt values (e.g. float32 values read from files): Be lenient? E.g. only make the comparison up to float 32 precision? See error above See snippet above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --

# objects, for speed.         if angles is None:             angles = self        lower = u.degree.to(angles.unit, -90.0)        upper = u.degree.to(angles.unit, 90.0)        upper = self.dtype.type(u.degree.to(angles.unit, 90.0))        lower = -upper         # This invalid catch block can be removed when the minimum numpy         # version is >= 1.19 (NUMPY_LT_1_19)         with np.errstate(invalid='ignore'):


Question: Printing tables doesn't work correctly with 0-length array cells

if multidims:             multidim0 = tuple(0 for n in multidims)             multidim1 = tuple(n - 1 for n in multidims)            trivial_multidims = np.prod(multidims) == 1            multidims_all_ones = np.prod(multidims) == 1            multidims_has_zero = 0 in multidims          i_dashes = None         i_centers = []  # Line indexes where content should be centered


Question: Printing tables doesn't work correctly with 0-length array cells

# Prevents columns like Column(data=[[(1,)],[(2,)]], name='a')                 # with shape (n,1,...,1) from being printed as if there was                 # more than one element in a row                if trivial_multidims:                if multidims_all_ones:                     return format_func(col_format, col[(idx,) + multidim0])                elif multidims_has_zero:                    # Any zero dimension means there is no data to print                    return ""                 else:                     left = format_func(col_format, col[(idx,) + multidim0])                     right = format_func(col_format, col[(idx,) + multidim1])


Question: Creating a mixin column in a new table from columns of another table renames columns in original table. Consider the following code, where a subset of columns from another table should be included in a new table with new names, prerably without copying the actual payload data: If any of the two classes or both are a , not a , the code works as expected. Data in the columns is not copied, but column names in original table stay the same. Column names do change in both tables: See above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --(also tested with current branch)

elif data_is_mixin:             # Copy the mixin column attributes if they exist since the copy below            # may not get this attribute.            col = col_copy(data, copy_indices=self._init_indices) if copy else data            # may not get this attribute. If not copying, take a slice            # to ensure we get a new instance and we do not share metadata            # like info.            col = col_copy(data, copy_indices=self._init_indices) if copy else data[:]             col.info.name = name             return col diff --git a/astropy/table/table_helpers.py b/astropy/table/table_helpers.py-- a/astropy/table/table_helpers.py++ b/astropy/table/table_helpers.py


Question: Creating a mixin column in a new table from columns of another table renames columns in original table. Consider the following code, where a subset of columns from another table should be included in a new table with new names, prerably without copying the actual payload data: If any of the two classes or both are a , not a , the code works as expected. Data in the columns is not copied, but column names in original table stay the same. Column names do change in both tables: See above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --(also tested with current branch)

"""     info = ArrayWrapperInfo()     def __init__(self, data):        self.data = np.array(data)    def __init__(self, data, copy=True):        self.data = np.array(data, copy=copy)         if 'info' in getattr(data, '__dict__', ()):             self.info = data.info


Question: Creating a mixin column in a new table from columns of another table renames columns in original table. Consider the following code, where a subset of columns from another table should be included in a new table with new names, prerably without copying the actual payload data: If any of the two classes or both are a , not a , the code works as expected. Data in the columns is not copied, but column names in original table stay the same. Column names do change in both tables: See above. <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --(also tested with current branch)

if isinstance(item, (int, np.integer)):             out = self.data[item]         else:            out = self.__class__(self.data[item])            out = self.__class__(self.data[item], copy=False)             if 'info' in self.__dict__:                 out.info = self.info         return out


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

coordinates in astropy. """ <ins>import functools</ins> from collections import namedtuple  import numpy as np


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

@staticmethod     def _convert_unit_to_angle_unit(unit):        return u.hourangle if unit is u.hour else unit        return u.hourangle if unit == u.hour else unit      def _set_unit(self, unit):         super()._set_unit(self._convert_unit_to_angle_unit(unit))


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

used.          decimal : bool, optional            If `True`, a decimal representation will be used, otherwise            the returned string will be in sexagesimal form.            If `False`, the returned string will be in sexagesimal form            if possible (for units of degrees or hourangle).  If `True`,            a decimal representation will be used. In that case, no unit            will be appended if ``format`` is not explicitly given.          sep : str, optional             The separator between numbers in a sexagesimal


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

unit = self._convert_unit_to_angle_unit(u.Unit(unit))          separators = {            None: {            'generic': {                 u.degree: 'dms',                 u.hourangle: 'hms'},             'latex': {


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

# 'latex_inline' provides no functionality beyond what 'latex' offers,         # but it should be implemented to avoid ValueErrors in user code.         separators['latex_inline'] = separators['latex']        if sep == 'fromunit':            if format not in separators:                raise ValueError(f"Unknown format '{format}'")            seps = separators[format]            if unit in seps:                sep = seps[unit]        # Default separators are as for generic.        separators[None] = separators['generic']          # Create an iterator so we can format each element of what         # might be an array.        if unit is u.degree:            if decimal:                values = self.degree                if precision is not None:                    func = ("{0:0." + str(precision) + "f}").format                else:                    func = '{:g}'.format            else:                if sep == 'fromunit':                    sep = 'dms'                values = self.degree                func = lambda x: form.degrees_to_string(                    x, precision=precision, sep=sep, pad=pad,                    fields=fields)        elif unit is u.hourangle:            if decimal:                values = self.hour                if precision is not None:                    func = ("{0:0." + str(precision) + "f}").format                else:                    func = '{:g}'.format            else:                if sep == 'fromunit':                    sep = 'hms'                values = self.hour                func = lambda x: form.hours_to_string(                    x, precision=precision, sep=sep, pad=pad,                    fields=fields)        elif unit.is_equivalent(u.radian):            if decimal:                values = self.to_value(unit)                if precision is not None:                    func = ("{0:1." + str(precision) + "f}").format                else:                    func = "{:g}".format            elif sep == 'fromunit':                values = self.to_value(unit)        if not decimal and (unit_is_deg := unit == u.degree                            or unit == u.hourangle):            # Sexagesimal.            if sep == 'fromunit':                if format not in separators:                    raise ValueError(f"Unknown format '{format}'")                sep = separators[format][unit]            func = functools.partial(                form.degrees_to_string if unit_is_deg else form.hours_to_string,                precision=precision, sep=sep, pad=pad, fields=fields)        else:            if sep != 'fromunit':                raise ValueError(f"'{unit}' can not be represented in sexagesimal notation")            func = ("{:g}" if precision is None else f"{{0:0.{precision}f}}").format            if not (decimal and format is None):  # Don't add unit by default for decimal.                 unit_string = unit.to_string(format=format)                 if format == 'latex' or format == 'latex_inline':                     unit_string = unit_string[1:-1]                if precision is not None:                    def plain_unit_format(val):                        return ("{0:0." + str(precision) + "f}{1}").format(                            val, unit_string)                    func = plain_unit_format                else:                    def plain_unit_format(val):                        return f"{val:g}{unit_string}"                    func = plain_unit_format            else:                raise ValueError(                    f"'{unit.name}' can not be represented in sexagesimal notation")        else:            raise u.UnitsError(                "The unit value provided is not an angular unit.")                format_func = func                func = lambda x: format_func(x) + unit_string          def do_format(val):             # Check if value is not nan to avoid ValueErrors when turning it into


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

s = f"{val}"             return s <ins>        values = self.to_value(unit)</ins>         format_ufunc = np.vectorize(do_format, otypes=['U'])         result = format_ufunc(values)


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

if angles is None:             angles = self         # For speed, compare using "is", which is not strictly guaranteed to hold,        # but if it doesn't we'll just convert correctly in the 'else' clause.         if angles.unit is u.deg:             limit = 90         elif angles.unit is u.rad:diff --git a/astropy/visualization/wcsaxes/formatter_locator.py b/astropy/visualization/wcsaxes/formatter_locator.py-- a/astropy/visualization/wcsaxes/formatter_locator.py++ b/astropy/visualization/wcsaxes/formatter_locator.py


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

is_latex = format == 'latex' or (format == 'auto' and rcParams['text.usetex'])              if decimal:                # At the moment, the Angle class doesn't have a consistent way                # to always convert angles to strings in decimal form with                # symbols for units (instead of e.g 3arcsec). So as a workaround                # we take advantage of the fact that Angle.to_string converts                # the unit to a string manually when decimal=False and the unit                # is not strictly u.degree or u.hourangle                 if self.show_decimal_unit:                    decimal = False                     sep = 'fromunit'                     if is_latex:                         fmt = 'latex'


Question: Unpickled Angle.tostring fails <!-- This comments are hidden when you submit the issue, so you do not need to remove them! --<!-- Please be sure to check out our contributing guidelines, . Please be sure to check out our code of conduct, . --<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted. If a similar issue is closed, have a quick look to see if you are satisfied by the resolution. If not please go ahead and open an issue! --<!-- Please check that the development version still produces the same bug. You can install development version with pip install command. --<!-- Provide a general description of the bug. --Pickling and unpickling an Angle object causes the tostring function to fail claiming hourangle and degree units cannot be represented in sexagesimal notation. <!-- Ideally a code example could be provided so we can run it ourselves. --<!-- If you are pasting code, use triple backticks (python import astropy.coordinates import pickle ang = astropy.coordinates.Angle(0.25 * ) pang = ((ang)) ang.tostring() pang.tostring() <!-- Even if you do not think this is necessary, it is useful information for the maintainers. Please run the following snippet and paste the output below: import platform; print(platform.platform()) import sys; print("Python", sys.version) import numpy; print("Numpy", numpy.version) import erfa; print("pyerfa", erfa.version) import astropy; print("astropy", astropy.version) import scipy; print("Scipy", scipy.version) import matplotlib; print("Matplotlib", matplotlib.version) --macOS-10.15.7-x86_64-i386-64bit Python 3.10.6 (main, Aug 22 2022, 20:43:44) [Clang 13.0.1 ] Numpy 1.23.4 pyerfa 2.0.0.1 astropy 5.1 Scipy 1.9.3 Matplotlib 3.6.1

if unit is u.hourangle:                             fmt = 'unicode'                         else:                            fmt = None                            fmt = 'generic'                     unit = CUSTOM_UNITS.get(unit, unit)                 else:                    sep = None                    sep = 'fromunit'                     fmt = None             elif self.sep is not None:                 sep = self.sep