Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: meas_astrom
-
Labels:
-
Story Points:14
-
Epic Link:
-
Team:Alert Production
Description
Implement Optimistic Pattern Matcher B in pure python outside of the stack for testing and better understanding of the algorithm.
Deliverable: Working python code.
Attachments
Issue Links
- is parent task of
-
- Done
Activity
Current working stand alone version can by find on my GitHub here:
https://github.com/morriscb/PythonOptimisticPatternMatcherB
Two files to look at are those with 3D in the name which are the 3D, spherical point matcher. The 3D matcher is also implemented in the u/morriscb/pythonOPMb branch of meas_astrom as a simple replacement to _doMatch in matchOptimisticB.py.
Things to look for:
Is there any optimization to be done in the matching methods of _construct_and_match_pattern and _pattern_spoke_test. In addition to these two you could check the _construct_rotation_matricies method.
Take a look at the testOPMb3D.py method to see if the tests are sufficient to verify the functionality of the code.
Beyond that general coding style comments and and suggestions of pythonic "tricks" that I am not currently using would be helpful.
In consultation with Simon Krughoff, the plan for this ticket is to mark this reviewed, since a prototype is clearly implemented and is currently being used as part of the matcher investigation. I think there's a nontrivial amount of refactoring to be done to the implementation before it's suitable for including into the stack but, we will defer that work to another ticket focused specifically on refactoring and integrating with other stack APIs. (Chris Morrison [X] can you link the ticket you use will use for that?)
A few general areas that I think could use work are:
- Reducing the amount of global state. (_construct_rotation_matricies() is a particularly bad offender, for example)
- The indexing into large shared arrays is particularly complicated (e.g. instances of start_idx and end_idx) and would be better to avoid, or at least isolate.
- Functions are very long and could be broken down. I'd really like to see a flowchart that lays out the steps (/functions) and the inputs/outputs to each step.
- Docstrings
Colin Slater
added a comment - In consultation with Simon Krughoff , the plan for this ticket is to mark this reviewed, since a prototype is clearly implemented and is currently being used as part of the matcher investigation. I think there's a nontrivial amount of refactoring to be done to the implementation before it's suitable for including into the stack but, we will defer that work to another ticket focused specifically on refactoring and integrating with other stack APIs. ( Chris Morrison [X] can you link the ticket you use will use for that?)
A few general areas that I think could use work are:
Reducing the amount of global state. ( _construct_rotation_matricies() is a particularly bad offender, for example)
The indexing into large shared arrays is particularly complicated (e.g. instances of start_idx and end_idx ) and would be better to avoid, or at least isolate.
Functions are very long and could be broken down. I'd really like to see a flowchart that lays out the steps (/functions) and the inputs/outputs to each step.
Docstrings
Completed initial prototype of the matcher. Will open a new ticket related to refactoring and fully stackifying the code.
Have currently implemented two versions of Optimistic Pattern Matcher B in Python: One runs on a tangent plane project and one runs in 3D points on the sphere. The 3D matcher appears to be more tolerant to noise in the object centroids.