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
The SOM layout will be defined with --layout, --som-width, --som-height, and --som-depth. To be prepared for future more complex layouts, e.g. growing self-organizing maps, the definition of the sizes should be part of the layout option, so that the new definition would be:
--layout cartesian 5 5 for a 2-dimensional quadratic map --layout cartesian 10 10 10 for a 3-dimensional quadratic map --layout hexagonal 11 11 for a hexagonal map
The text was updated successfully, but these errors were encountered:
Does it make much sense to have the internals in pink always treat a SOM as a three-dimensional one? A 2D SOM is just a special case of a 3D SOM. Or is the idea to allow an arbitrary number of dimensions? Dare I say four dimensions?
For my own code that I use to interact with the binary files I always convert coordinates to a 3D type scheme to help minimize the number of cases to write.
The layout SOM and data should be full generic. For the cartesian layout n should be an arbitrary number. Future ideas are also nested layouts or tree structures for a SOM. In the main code the generic design is implemented. Only in some heritage code, like InputData, old C structures will be used.
The SOM layout will be defined with
--layout
,--som-width
,--som-height
, and--som-depth
. To be prepared for future more complex layouts, e.g. growing self-organizing maps, the definition of the sizes should be part of the layout option, so that the new definition would be:--layout cartesian 5 5
for a 2-dimensional quadratic map--layout cartesian 10 10 10
for a 3-dimensional quadratic map--layout hexagonal 11 11
for a hexagonal mapThe text was updated successfully, but these errors were encountered: