Regression in WCS.invert() API due to #498?

[jehturner]

In gwcs >=0.22, the invert() method now produces a traceback when passed Table row/column values as the co-ordinate args to be transformed. This doesn't seem like an intentional API change (? the doc string says float, array like, SkyCoord or Unit) and the equivalent forward WCS.__call__() does not have this problem.

from astropy import table, units as u, coordinates as coord
from astropy.modeling import models as m
from gwcs import WCS, coordinate_frames as cf

detector_frame = cf.Frame2D(name="detector", axes_names=("x", "y"),
                            unit=(u.pix, u.pix))
sky_frame = cf.CelestialFrame(reference_frame=coord.ICRS(), name='icrs',
                              unit=(u.deg, u.deg))
det2sky = m.Identity(2)

wcsobj = WCS([(detector_frame, det2sky),
              (sky_frame, None)])

td = table.Table([[1024.], [1024.]], names=('x', 'y'))
tw = table.Table([[156.0169334], [-57.7858117]], names=('RAJ2000', 'DEJ2000'))

wcsobj(td['x'], td['y'])  # works
wcsobj.invert(tw['RAJ2000'], tw['DEJ2000'])  # fails

Traceback (most recent call last):
  File "/home/jturner/pipeline_test/gwcs_test.py", line 18, in <module>
    wcsobj.invert(tw['RAJ2000'], tw['DEJ2000'])  # fails
  File "/home/jturner/miniforge3_23.1.0/envs/test/lib/python3.10/site-packages/gwcs/wcs.py", line 462, in invert
    args = self.output_frame.coordinate_to_quantity(*args)
  File "/home/jturner/miniforge3_23.1.0/envs/test/lib/python3.10/site-packages/gwcs/coordinate_frames.py", line 400, in coordinate_to_quantity
    raise ValueError("Could not convert input {} to lon and lat quantities.".format(arg))
ValueError: Could not convert input (<Column name='RAJ2000' dtype='float64' length=1>
156.0169334, <Column name='DEJ2000' dtype='float64' length=1>
-57.7858117) to lon and lat quantities.

I believe this happens because of a change to utils.isnumerical() in #498, which now explicitly returns False for table Row/Column objects. I'm not 100% sure what the intention was there, but I think tables without units should probably be treated in the same way as a numpy array. Note that this problem occurs even if the table values do have units (which, in any case, wasn't a requirement before).

Thanks!

James.

[WilliamJamieson]

This was never intentionally supported and the documentation was not entirely correct. I suggest you simply convert your columns into arrays before passing them in.

[jehturner]

OK, thanks -- but 1) why were table.Column and table.Row explicitly added to the co-ordinate checks in utils.isnumerical if they weren't intended to work? and 2) wouldn't it obviously be convenient for this to have the option of passing in co-ordinate table values (particularly for interactive use)? Maybe I could send a PR for this if the problem/requirements are clarified a bit and it's not unduly complicated for some reason? What is the use case for table rows/columns returning False now?

Cheers,

James.

[WilliamJamieson]

The utils.isnumerical method has been removed.