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
Currently we have only additive update operation (in both VectorStorage and MapStorage). A user interface is needed to customize the update operation. Also, some operations may need to be executed after finishing each iteration.
Below are some examples:
Customizable update: For regularization, since the update is dense, it is better carried out on the server side. Thus for each Add or Clock request, the servers need to regularize the model partition.
Operations after finishing iteration: Algorithms like K-Means and SVRG (in the synchronized execution) need to reset the table after each iteration.
For now we may subclass VectorStorage or MapStorage with a new SubAdd logic and register new constants in the engine for creating tables with the new storage type. Similar things could apply for new model type with a different Clock logic. However, this needs quite some tedious work every time a new storage or model type is needed. We should have an extensible interface for creating tables in the engine.
About "tedious work": users need to understand the low level system details (Engine::CreateTable and KVEngine::CreateTable), and modify system codes accordingly.
The text was updated successfully, but these errors were encountered:
Currently we have only additive update operation (in both
VectorStorage
andMapStorage
). A user interface is needed to customize the update operation. Also, some operations may need to be executed after finishing each iteration.Below are some examples:
Add
orClock
request, the servers need to regularize the model partition.For now we may subclass
VectorStorage
orMapStorage
with a newSubAdd
logic and register new constants in the engine for creating tables with the new storage type. Similar things could apply for new model type with a differentClock
logic. However, this needs quite some tedious work every time a new storage or model type is needed. We should have an extensible interface for creating tables in the engine.About "tedious work": users need to understand the low level system details (Engine::CreateTable and KVEngine::CreateTable), and modify system codes accordingly.
The text was updated successfully, but these errors were encountered: