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
Current class hierarchy comes from analysis of proton beams. I think we can easily get rid of some of the classes and move some of them (i.e. LateralProfile, DistalProfile) to user code: examples etc...
We need a clear separation of responsibilty between various classes. At the beginning I would start with two:
Curve - general class to represent set of (x,y) pairs where x coordinates is in ascending order
Profile - subclass of Curve, for which y coordinates are first more-less increase and them more-less descrease
For Profile it might sense to calculate width, fwhm and other features based on rising-falling character, which for Curve - not.
The text was updated successfully, but these errors were encountered:
Current class hierarchy comes from analysis of proton beams. I think we can easily get rid of some of the classes and move some of them (i.e. LateralProfile, DistalProfile) to user code: examples etc...
We need a clear separation of responsibilty between various classes. At the beginning I would start with two:
For Profile it might sense to calculate width, fwhm and other features based on rising-falling character, which for Curve - not.
The text was updated successfully, but these errors were encountered: