caten2 / tripods2021ua Goto Github PK

I implemented generalized composition as a method of Operation in order to help clean up the code and debug more effectively. Since feeding forward is nothing but evaluating the tuple of operations represented by the neural net on given inputs, I'd like to hear some input on whether or not we should reimplement feeding forward as an application of this generalized composition method.

The class Relation is defined in src/relations.py, so one would imagine that the class Operation would be defined in src/operations.py, but this is not the case. The current operations defined in src/operations.py are arithmetic operations use in more basic examples/testing for the discrete neural net setup, and these should be moved somewhere like src/arithmetic_operations.py. Meanwhile, src/operations.py should contain the Operation class.

The dominion polymorphisms need to be implemented using the new Relation class. There are a few parts of this:

1. Right now there is a directory in the project root called mnist. This should probably be changed to a more organized data directory in the project root which can contain the files generated in the course of constructing dominions.
2. Once the dominion polymorphisms are reimplemented, they should be included in the polymorphism_neighbor_func in src/polymorphisms.py.
3. It may make sense to include the definition of the actual dominion polymorphisms (as Operations) in src/polymorphisms.py, even if there is still some auxiliary script like src/dominion.py which is used in the construction of the requisite data.

As the title says, it will be helpful to have the neighbor function polymorphism_neighbor_func in src/polymorphisms.py defined for polymorphisms of higher-arity relations. The higher-arity case may have to have the dominion polymorphisms disallowed, unless those have been generalized to the higher-arity case already.

1. Already the BlankingEndomorphism, SwappingAutomorphism, and IndicatorPolymorphism polymorphisms work for relations of any arity, so it remains address the hyperoctahedral automorphisms.
2. It needs to be decided whether to implement hyperoctahedral automorphisms by always just choosing a random signed permutation, only allowing a (minimal) generating set, or to have an option to toggle between these behaviors. (This last one would be ideal if we want to test which approach seems faster.)

In an early version of this project, Andrey Yao had added visualization for the NeuralNet objects with Graphviz. It would be nice to be able to generate images of neural nets with the following information:

1. The architecture of the neural net.
2. The activation function at each neuron. (Perhaps using a more informative __str__ method for the various subclasses of Operation.)
3. Optionally, a depiction of what feeding forward looks like for some inputs into the neural net. This could be combined with the display method(s) for binary relations addressed in #22. This could show the value of each activation function on its inputs, providing there is enough space.

As you can see in the current version of src/relations.py there is a show method for the Relation class which has an optional argument of special_binary_display. This could be improved in a number of ways to help with visualizing binary relations. This issue is pretty open-ended, but here are some suggestions for ways to improve this.

1. Instead of the existing options, one could have a general method where the true/false values can be represented by any chosen characters or even strings. For example, the choice 'binary_pixels'would correspond to sending true to 1 and false to 0.
2. We don't have to just output by printing something. You could also output latex source code that describes a matrix of entries, or even use tikz or asymptote to draw something.
3. It's not necessary to create a literal picture. We could also represent a binary relation as a directed graph, for example. Another possibility is grouping, say 2 by 2 blocks of the image together and then using a greyscale value to represent how many pixels in the 2 by 2 block are black.
4. You might also consider an option where you save an image file or save any code you generate as a text file instead of printing it out. If you want to make images to save, one option is Mathplotlib.

The script src/polymorphisms.py now contains the definitions of the Hamming graph polymorphisms, but the hyperoctahedral ones have yet to be added to it. The script src/binary_image_polymorphisms.py remains so that the work found there isn't lost, but most of it has been moved over and, in some cases, improved. For example, SwappingAutomorphism and BlankingEndomorphism now work for relations of arbitrary arity, not just binary ones.

Once the hyperoctahedral automorphisms have been implemented, we still need to decide whether to keep the original RotationAutomorphism and ReflectionAutomorphism or perhaps make these aliases for specific cases of the general hyperoctahedral implementation.