Closed IrwinChay closed 10 months ago
Alternative: use a "sum product node" class to store the CP and Tucker placeholder parameters? instead of storing everything in the sum node class?
As just discussed: (to keep a note here)
"Building symbolic circuit from RG" will be implemented in another file, writing now
Better include it in this PR, which also requires some changes to the __init__
interface.
Alternative: use a "sum product layer" class to store the CP and Tucker placeholder parameters? instead of storing everything in the sum layer class?
It's better to split sum and prod in symbolic layers. Fusing them into SumProductLayer with einsum is just a computational trick but not the semantics of circuit.
Also some nomenclature renamings mentioned in discussion.
Update:
renamed from node to layer, num_input_units into num_units, product layer type
Added CP parameter construction
Added symbolic circuit class, construction from Region Graph, compatibility test,
re-arranged folder structure to /new/symbolic
For linting, just ignore for the moment. Will be looked after during future refactoring.
Regarding
SymbolicCircuit
:
from_region_graph
should directly become__init__
because SC can only be constructed from RG. We don't needadd_layer
andadd_edge
publicly.- Just save a copy of RG, and the structural properties can be directly retrieved from the RG. NO need to repeat code and recalculate.
Update:
moved from_region_graph
to __init__
removed smooth and decomposability tests, which are copies of that in RG
retained is_compatible
, will move it to new/RG
Basically following what we discussed in week 8,
specifically, using re-param for placeholder (uninitialized) parameters
Also stored all the information (layer_cls and efamily_cls) so the tensorized circuit could be directly converted into tensorized form, no additional input needed
CP layers and sum layer (previously called mixing layer) not implemented yet
"Building symbolic circuit from RG" will be implemented in another file, writing now