Fix FeatureGenerator gives wrong units

[kosack]

FeatureGeneartors currently support both Table and QTable as inputs, and both are tested. However, unit propagation is wrong when aTable with units is used.

E.g., if a source column x has units m, a generated column x**2 should have units m2, but does not if the input table is of class Table, where it retains the incorrect unit m. Unit propagation works for QTables. See the test I added to this PR, which currently fails.

I found this when looking into a simpler implementation for #2919 .

Possible solutions:

• require QTables in ExpressionEngine, and raise an exception if a Table is passed.
• Convert all Tables to QTables in __call__() (breaks current tests where a feature column calls col.quantity.unit)

The reason is that Astropy does not do unit math for columns automatically (which I think is actually quite a strange choice)

>>> table = Table(dict(x=np.arange(11)*u.cm)
>>> table["x"]**2
<Column name='x' dtype='float64' unit='cm' length=11>
  0.0
  1.0
  4.0
  9.0
 16.0
 25.0
 36.0
 49.0
 64.0
 81.0
100.0

[kosack]

Do we rely anywhere on using FeatureGenerator on Tables with unit columns? If not, I can modify the tests and change the API to explicilty require QTables. Supporting both is somewhat annoying.

EDIT: I decided to simply change to using internal conversion to QTable, which has the side effect of not allowing one expression we previously tested: "log10(length.quantity.to_value(u.m))" now must be "log10(length.to_value(u.m))"

[maxnoe]

We should just add QTable(table, copy=False) to the call function I think. That's a very cheap operation.

[kosack]

Once #2923 is merged, the docs here should pass.

[maxnoe]

Docs build is fixed in main, please rebase

[ctao-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
85.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube