jo-pol
commented
9 years ago This issue shifts more or less from the template based diagrams to the D3.js based diagrams. The latter ones needs another variant than prepared for the first and only for interleaved matrices.
The source graph.scala is quite large due to the hard coded matrices. The hashmap even runs into limits ob object size when not constructing it from other objects. Though the JavaScript generated from the scala sources is cached and transferred in a zipped form, too many matrices may cause occasional unacceptable load time.
It is not necessary to store both incoming and outgoing pairs for each stitch in a tile. The incoming pairs can be deduced from the outgoing pairs or vice versa to reconstruct the full tuples. Outgoing pairs for interleaved tuples have 10 permutations, diagonal tuples even less. So a matrix can be stored with a string containing just a single decimal digit per stitch. It must be strings as integers range little over 9 digits and we need 16 for 4x4 matrices. For the size of the source code string or integers hardly matter. Eliminating the deduction of incoming from outgoing pairs, we have 70 permutations, meaning digits plus the alphabet in lower case and upper case and 6 more characters (or the ASCII characters [0-Za-y]) would result in the same string length. A simple hashmap can convert these characters to the desired tuples.