Regarding the details of the experiment

[1d1x1w]

Recently, the ProDe method was replicated on OfficeHome, but the final results were not as high as claimed in the paper. Basically, there is a difference of 1-2%. May I ask if the author can provide a checkpoint, and is it possible that the OPTIM.LR_DECAY3 in the source code was not used in the method due to a coding error? Can you provide specific learning rate settings for both netF and netC, which use OPTIM.LR_DECAY1?

[1d1x1w]

What exactly does logits_mank in 214-228 in ProDe.py do, why is source data used, and there are many confusing and strange places in the code. And why is the loss that runs out negative?

    num_sample = len(dset_loaders["target"].dataset)
    logtis_bank = torch.randn(num_sample, cfg.class_num).cuda()     # [target number, n_cls]

    loader = dset_loaders["source"]     # target data
    with torch.no_grad():
        iter_test = iter(loader)
        for i in range(len(loader)):
            data = next(iter_test)
            inputs = data[0]
            indx = data[-1]
            inputs = inputs.cuda()
            output = netB(netF(inputs))
            outputs = netC(output)
            outputs = nn.Softmax(dim=1)(outputs)
            logtis_bank[indx] = outputs.detach().clone()

[Kalaniik]

Thank you very much for your detailed feedback and for taking the time to reproduce the ProDe results.

1. Regarding the replication on OfficeHome, we have also conducted multiple validation experiments on different servers. The results typically vary within about 1%, which can be attributed to differences in hardware environments and random process. To verify that the method itself is correct, we have provided the output logs for the AC split on OfficeHome.

2. As for the OPTIM.LR_DECAY3 parameter, you are correct — it is not used in the final ProDe implementation. This is not a coding error; it was included for earlier comparison experiments and remained in the configuration file. Please feel free to ignore it.

3. The learning rate settings for both netF and netC can be found in the source code between lines 179–196, where the computation and scheduling process are defined in detail.

4. Regarding the section lines 214–228 in ProDe.py, you are absolutely right that the earlier uploaded version corresponded to the “ProDe-V w/o PD-logits” variant used in the ablation study (Table 8) of the paper. The code has now been corrected and updated — thank you for pointing this out.
   Additionally, please note that this part does not use the source data directly. Instead, it stores the target domain data outputs from the source model, which are later used in the proxy denoising process.

We really appreciate your careful examination and constructive feedback — it helps us improve the project for everyone.

log_par_0.4.txt