[FIX] NormalizePhaseReference.transformed() should not return a Table

[stuart-cls]

_NormalizePhaseReferenceCommon.transformed() would return a Table instead of an array when the table had length 0

This is what the previously failing test (test_no_samples) is supposed to check, but I'm not sure why it was only failing in the latest dask branch?!

[markotoplak]

Thanks!

[stuart-cls]

I'm going to merge this, but I'm a little concerned that the existing test didn't catch this bug.

[markotoplak]

This is why I did not merge because I wanted to see why the difference. It is entirely possible that DaskTable and Table behave differently in edge cases.

If the table was really empty (= had no rows) then the transformation should not do anything with the result of this function and theoretically it would not need to matter what it returns in these cases. But seems like different things are executed...

[stuart-cls]

Oops, sorry Marko! This function was definitely being called in the test but I didn't follow further to see what was being done with the result. One surprising thing is I don't think the dataset tested here is actually loaded as DaskTable. It may be a funny interaction between the thread cacheing stuff in Table and the dask.distributed.LocalCluster which also uses threading.

[markotoplak]

The dask branch also has refactored table transformations. Perhaps something is different there. :)

[markotoplak]

I checked. The dask branch code does not have any exceptions when transforming zero-length tables. So it still expects arrays of proper sizes (and row-size 0 :) ) on transformation outputs.

I am not completely sure whether that was a smart choice. It surely makes the transformation code shorter because otherwise we'd have to write a new functions that makes a "blank" zero-row arrays of certain sizes and types, but it also unmasks bugs like this.

[stuart-cls]

I think it's better to keep the .transformed() functions simple and without tricky conditionals (as fixed in this PR). It doesn't make sense to me to have the function returning completely different types depending on the Table length.

I suppose the issue is if the underlying transforming code that is called doesn't support zero-row arrays, then we're back to having to handle that in the transformed() function.

Could there be some typing to indicate what the table transformation code is expecting? I guess that wouldn't help with the array size issue.