singa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SINGA-42) Issue when loading checkpoints
Date Wed, 09 Dec 2015 11:03:11 GMT


ASF subversion and git services commented on SINGA-42:

Commit f16b1be6f1d30f3ad3554c52359a69c2f643cd61 in incubator-singa's branch refs/heads/master
from [~zhaojing]
[;h=f16b1be ]

SINGA-107 Error from loading pre-trained params for training stacked RBMs

When Params are loaded from checkpoint files, their version numbers will be reset to 0 for
fine-tuning as explained in the comments of SINGA-42.
However, if these parameters are not fine-tuned (For example, in,
in RBM2, the parameters from RBM1 are not updated), then these parameters' versions would
be 0 when they are dumped into the checkpoint files. When these parameters are loaded again
for training other models, their versions are 0, hence they should be initialized again according
to SINGA-42. In other words, the pre-training is useless.

Currently solution is loading the checkpoint file where each Param is first dumped, so that
the latter (correct) Param can override the in-correct Param. Consequently, the version number
will not be 0.
For example, in
, we configure the checkpoint files as:

checkpoint_path: "examples/rbm/rbm2/checkpoint/step6000-worker0"
checkpoint_path: "examples/rbm/rbm1/checkpoint/step6000-worker0"

in order to load w1 and b12 correctly.

> Issue when loading checkpoints 
> -------------------------------
>                 Key: SINGA-42
>                 URL:
>             Project: Singa
>          Issue Type: Bug
>            Reporter: ZHAOJING
> When I try loading checkpoints of 4 pretrained RBM models in order to train a deep autoencoder,
the program is stuck. 
> The problem comes from reseting the version of params loaded from checkpoint file. After
we modify 
> "optional bool reset_param_version = 67 [default = false];" to "optional bool reset_param_version
= 67 [default = true];" 
> in src/proto/job.conf. The problem is resolved.

This message was sent by Atlassian JIRA

View raw message