Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-8110

Implement matcher prototype

    XMLWordPrintable

Details

    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

          Activity

            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.

            cmorrison Chris Morrison [X] (Inactive) added a comment - 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.

            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.

            cmorrison Chris Morrison [X] (Inactive) added a comment - 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.
            ctslater Colin Slater added a comment -

            In consultation with 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. (cmorrison 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
            ctslater Colin Slater added a comment - In consultation with 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. ( cmorrison 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.

            cmorrison Chris Morrison [X] (Inactive) added a comment - Completed initial prototype of the matcher. Will open a new ticket related to refactoring and fully stackifying the code.

            People

              cmorrison Chris Morrison [X] (Inactive)
              cmorrison Chris Morrison [X] (Inactive)
              Colin Slater
              Chris Morrison [X] (Inactive), Colin Slater
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.