A python package to read, export and post process data (*.pnt files) recorded by SnowMicroPen, a snow penetration probe for scientific applications developed at SLF.
Currently there is a bit of a clash between object oriented data classes and a more functional style of programming for the Physics. This is natural for GUIs controlling data output. Still, there is a bit of a backlog from the times snowmicropyn seemed to mainly have been for displaying the SMP forces.
Issues can usually be worked around because the structure is generally good, but there is some overhead, loss of clarity, and loss of elegancy (e. g. by having to put instructions in locations that feel out of place).
This gap is partly bridged by the Document class, which holds a profile and some derived values (e. g. drift fit), but it is GUI oriented and does not do all that much. In fact this is now where the AI stuff is called from, because it cannot be done from Profile or CAAML for logical reasons (attempts rightfully fail in circular includes). It works out, but in the CAAML unit test for example we have to include something from pyngui even though it has nothing to do with the GUI.
Instead of or in addition to this Document class for the GUI I propose a new class Pit which holds a) the profile and b) meta data including several derived properties (if we want full backwards compatibility we may need to just keep and extend the existing Document).
Depending on how much time is spent this could have a big reach:
Derivatives would have a central place to sit. Currently with the functional calls it is up to the user/developer to save this some place and keep in sync when options change. For example, the plot function calculates the values and stores them, the CAAML export calculates and stores them, and so does the normal csv output, separately.
This class could cache the data and recalculate only if necessary.
Opens up the possibility for lazy evaluation - i. e. don‘t only recalculate if necessary, but also calculate only if needed.
It could handle things like hiding the air gap transparently - different GUI features would not have to handle it themselves (superposition).
Should facilitate parallelization in the future.
Would fit the modules we currently have neatly: Pit would be parent of a static Profile with measurements and recorded meta data only, a derivatives object for low level parameterizations, a classifier object for machine learning, and the Pit would also be the place to house the final export where all of this is combined.
Probably, this class should also manage dynamic warping in the future. We could already include this in the object factories etc. and then existing code could hopefully be integrated more easily (as the framework would already exist).
Apart from the always looming refactoring in open source projects this point could be tackled separately while still having great overall ramifications. However, it is not a quick fix at all.
Currently there is a bit of a clash between object oriented data classes and a more functional style of programming for the Physics. This is natural for GUIs controlling data output. Still, there is a bit of a backlog from the times snowmicropyn seemed to mainly have been for displaying the SMP forces. Issues can usually be worked around because the structure is generally good, but there is some overhead, loss of clarity, and loss of elegancy (e. g. by having to put instructions in locations that feel out of place).
This gap is partly bridged by the
Documentclass, which holds a profile and some derived values (e. g. drift fit), but it is GUI oriented and does not do all that much. In fact this is now where the AI stuff is called from, because it cannot be done fromProfileorCAAMLfor logical reasons (attempts rightfully fail in circular includes). It works out, but in the CAAML unit test for example we have to include something frompynguieven though it has nothing to do with the GUI.Instead of or in addition to this
Documentclass for the GUI I propose a new classPitwhich holds a) the profile and b) meta data including several derived properties (if we want full backwards compatibility we may need to just keep and extend the existingDocument).Depending on how much time is spent this could have a big reach:
Pitwould be parent of a staticProfilewith measurements and recorded meta data only, aderivativesobject for low level parameterizations, aclassifierobject for machine learning, and thePitwould also be the place to house the final export where all of this is combined.Apart from the always looming refactoring in open source projects this point could be tackled separately while still having great overall ramifications. However, it is not a quick fix at all.
Just my 2 cents!