Inter-architecture weights mapping

[metric-space]

• Ensure MergePlanner takes into account differing architectures as opposed to how things were previously ( the same architecture was expected of all models to be merged)

How does this work?

A mapping is defined as a json file between the base model and each model to be merged in. Specifically at the pre/post weights level

Each json file corresponds to a base-architecture to destination pair (though the actual direction is the reverse)

an example of this is

{
    "start_architectures": ["A"],
    "destination_architectures": ["B"],
    "weights_mapping":{
        "a" : "d",
        "b" : "e",
        "c" : "m"
    }
}

Notes:

1. string templates are allowed in both keys and values
2. at this time only isomorphic mappings are considered at all levels

[cg123]

Thanks for getting to those changes! Looking pretty good now - I had a few more thoughts before we get this merged.

[cg123]

whoops, sorry for missing that dependency!

[cg123]

👍 I think we actually need to loop over layers here though - if there's a ${layer_index} reference in a template we need to populate it for each value of layer_index. (If you have thoughts on how to make the whole template setup cleaner I'd definitely appreciate them - it's a little silly at the moment.)

[metric-space]

I was careless. I set out out to do exactly that and somehow meandered away. I will make this correction

[cg123]

Slight style nitpick: I tend to prefer having type annotations for members in the top level of the class (like in lines 47-50) instead of at first assignment like you have here.

[cg123]

I think this logic isn't quite right. Consider a merge with two models (aside from the base) - the first is the same architecture as the base and the second is a different architecture. This will see that the first model has the same architecture and break out of the loop, so the second will not get overrides set.

[metric-space]

Perhaps I'm missing something but the inner most loop loops through the alternate names of both architectures and breaks if it has found a match
But the outermost loop takes care of the actual model list traversal

unless break breaks out of both the loops which I don't think is the case, this should be fine. It is possible I'm overlooking something very trivial

[cg123]

Oh, you're absolutely right, sorry about that - I missed the outer loop. Disregard!

[metric-space]

I wonder if I should name things better? I believe the naming of things as of now is very likely to throw the reader off. What do you think?