Question about the meaning of parser.simple

[Uio96]

I have seen your previous notes in #5 (comment) and #2 (comment). Based on my current understanding, this subclass of the perceiver can perform some complex processing tasks.

But I am still confused about the meaning of parser.simple. There seems to be some overlapping between parser.simple and parser.fromLayer. Both of them are going to instantiate puzzle pieces from image source and puzzle template mask. What is the difference between them?

Another question is about creating a board instance in simple.py. The state obtained in the tracker (centroid or centroidMulti) is different from a board instance. Should we do something else?

I put my question in https://github.com/ivapylibs/puzzle_solver/blob/master/puzzle/parser/simple.py#L77-L84

[pv33]

@Uio96
parser.simple is a perceiver.
parser.fromLayer is a trackpointer.

That distinction alone should be enough.

The parser.fromLayer cannot do complex image processing. The parser.simple, as a perceiver, contains a detector which can implement more complex image processing. At the moment, the codebase does not yet perform more complex processing, thus all of the implementation will appear to be the same. This is what happens when things get built up from nothing and follow my motto of starting from a position of strength and using TDD/BDD, where "strength = simple test cases with absolutely known outcomes that are fast to code up." You are getting hung up on the indistinction of the current implementation as opposed to conceiving of the more complex activities that could be done, mostly because you lack the experience to even know what they might be (this is my conjecture as to why it seems you can't get past the hang up in spite of the documentation. The current issue here I am responding to is a variation on another issue or Trello question that had the exact same answer in spirit if not in function).

The whole point of parser.fromLayer is to create a trackpointer instance that creates a puzzle.board as a measurement. Thus your question of "Should we do something else?" is already answered in the positive (as in YES we should ... ) through the existence of the parser.fromLayer. The parser.fromLayer builds a puzzle.board and requires you to keep track of more complex image information than the current trackpointer.multiCentroid does. Please note that puzzle.manager is then a sub-class of parser.fromLayer with this class derivation sequence noted in the codebase and in the issues (I think).

A parser.simple would have a parser.fromLayer as its trackpointer. It can also have a puzzle.manager as its trackpointer. There may end up being all kinds of other trackpointer instances that the parser.simple will employ when this project is said and done.

Naturally, it is possible to setup the parser.simple to contain the parser.fromLayer and to have trivial detection, in which case they would both have the exact same functionality. In fact, this would be the most basic test case for the parser.simple and may even be in the documentation/issues already. (confirm: not explicitly in git repo as a test file, so not in documentation. but yes explicitly in the issue comments for the parser.simple here with it being your responsibility to create the test script).

I get the sense that you are not reading the issue comments as fully as you could be.

• Yunzhi: Please confirm that you have read the comments and understand the code development ordering that builds up from detector to trackpointer to perceiver. While Yiye is more focused on the detector parts, the code here is less focused on that, thus there are little to no issues attached to the detector package. Eventually there will be.

The issues in the milestone are in order of programming / assignment for you to complete. I did not communicate that, but did think it should have been noted when looking at the milestone and seeing the issue dependency chain (which links back to which). The order is:

puzzle.piece ➡️ puzzle.board ➡️ puzzle.fromLayer ➡️ parser.simple (by way of a detector.noneLayered or detector.layeredNone based on your naming preference).

Once done, the entire process gets an upgrade in the form of a puzzle.manager which inherits from puzzle.fromLayer.

[pv33]

@Uio96
As homework and for self-clarification, you should draw out the class dependencies and write a short sentence explaining the role of each class. Have it ready for discussion on Monday.

[Uio96]

Thank you for the detailed clarification. I only noticed that parser.fromLayer would be the superclass of puzzle.manager. But I did not notice the connection between it and parser.simple. I will draw a map of class dependencies for tomorrow's meeting.

[pv33]

@Uio96
Just note that dependencies is more than inheritance. It includes what each class contains and how those contained classes relate to the hierarchy and to the desired functionality.

The class visualization should attempt to make sense of the desired functionality. Thus, part of the visual needs to also include anticipated functionality and how the instances support the functionality. It would be an explanation layer of the visualization. In my mind I see the class hierarchies on the left along with color coded containment arrows. On the right I see functionalities with explanations that connects them to the classes.