Changes to linop.xray.astra module

[bwohlberg]

Changes to linop.xray.astra module:

• Add missing typing
• Fix some docstrings
• Change interface of convert_to_scico_geometry

Note:

• Typing still needs some attention. In particular, it's not always clear whether jax or numpy arrays should be specified, and jax.ArrayLike should perhaps be replaced by numpy.typing.ArrayLike.
• Some functions do not have any docstrings.

[Michael-T-McCann]

* Typing still needs some attention. In particular, it's not always clear whether `jax` or `numpy` arrays should be specified, and `jax.ArrayLike` should perhaps be replaced by `numpy.typing.ArrayLike`.

Putting the specific issue of this module aside, do we have a policy about this for SCICO? For example, jax.numpy functions are annotated with jax._src.typing.ArrayLike -> jax._src.typing.Array (documented here, includes NumPy inputs), whereas LinearOperator.__call__ is Union[LinearOperator, Array, BlockArray] -> Union[LinearOperator, Array, BlockArray] (does not include NumPy inputs).

For this module, it would be convenient if at least JAX inputs were allowed for everything, with internal conversion to NumPy when ASTRA requires it.

[bwohlberg]

Putting the specific issue of this module aside, do we have a policy about this for SCICO? For example, jax.numpy functions are annotated with jax._src.typing.ArrayLike -> jax._src.typing.Array (documented here, includes NumPy inputs), whereas LinearOperator.__call__ is Union[LinearOperator, Array, BlockArray] -> Union[LinearOperator, Array, BlockArray] (does not include NumPy inputs).

I don't recall this has ever been discussed in detail. If both jax and numpy array inputs are reasonable, then a Union would make sense. It's often clear, though, what the output type will be if there's an explicit jax.numpy or numpy call in the processing chain.

For this module, it would be convenient if at least JAX inputs were allowed for everything, with internal conversion to NumPy when ASTRA requires it.

That seems fine.