You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reviewing Pull Request #375 a substantial conversation was started around the fact that confocal logic has 'x', 'y', 'z' axes hard-coded into its class attribute names (for example, image_x_range). It is better to continue that conversation here as an issue separate from the immediate needs of that pull request (which have been simplified into a quickfix at #378).
There are a few separate questions:
Should confocal logic be able to handle arbitrary axis names, or is that something for the hardware module?
Should confocal logic be able to handle arbitrary coordinate systems (cartesian, polar, cylindrical, spherical, hyperbolic, etc)?
If it should handle arbitrariness of either kind, how should this be implemented (dictionary, namedtuple, base class inherited into specific daughter classes, etc)?
The text was updated successfully, but these errors were encountered:
While reviewing Pull Request #375 a substantial conversation was started around the fact that confocal logic has 'x', 'y', 'z' axes hard-coded into its class attribute names (for example, image_x_range). It is better to continue that conversation here as an issue separate from the immediate needs of that pull request (which have been simplified into a quickfix at #378).
There are a few separate questions:
Should confocal logic be able to handle arbitrary axis names, or is that something for the hardware module?
Should confocal logic be able to handle arbitrary coordinate systems (cartesian, polar, cylindrical, spherical, hyperbolic, etc)?
If it should handle arbitrariness of either kind, how should this be implemented (dictionary, namedtuple, base class inherited into specific daughter classes, etc)?
The text was updated successfully, but these errors were encountered: