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
Similarly to issue #67 , there are other places in the codebase that could benefit from being streamlined into a single codepath.
A few functions call similar-but-not-quite-the-same codepaths, which introduces extra complexity in understanding program state. Perhaps some functions could benefit from being renamed, or not overloaded, too.
ModelLists and mappings also have many similar stages, but sometimes call different functions due to the multi scale handling. It seems like it might be worthwhile to consider ModelLists as multi-scale models with only a single implicit scale (without making the API more complex on the user side). There is at least one difference worth keeping, which is that with a single scale the size of the output data can be known exactly and preallocated in advance.
The text was updated successfully, but these errors were encountered:
Issues such as issue #85 might also arise less often in the future with code flow that only splits right when specialization is needed, instead of having two more distinct but still functionally similar codepaths
Given that there are some distinct differences between single and multiscale use cases, and that there is a modellist to mapping comparison that should help ensure the two cases don't desynchronise, it might be worth calling this issue closed.
Similarly to issue #67 , there are other places in the codebase that could benefit from being streamlined into a single codepath.
A few functions call similar-but-not-quite-the-same codepaths, which introduces extra complexity in understanding program state. Perhaps some functions could benefit from being renamed, or not overloaded, too.
ModelLists and mappings also have many similar stages, but sometimes call different functions due to the multi scale handling. It seems like it might be worthwhile to consider ModelLists as multi-scale models with only a single implicit scale (without making the API more complex on the user side). There is at least one difference worth keeping, which is that with a single scale the size of the output data can be known exactly and preallocated in advance.
The text was updated successfully, but these errors were encountered: