learning FactorGraphModel #1538
Conversation
|
Hi @hushell! What about starting off by separating the CMake part from the rest? I think that each of them is worth a separate pull request and also their own commits. |
|
Sounds great! So I send 2 PRs at the same time? |
|
Yep, you just need to submit them from different branches. |
|
updated! :) |
| w[5] = 0.6; // 0,1 | ||
| w[6] = -0.2; // 1,1 | ||
| w[7] = 0.75; // 1,1 | ||
| //float64_t w_norm = SGVector< float64_t >::twonorm(w.vector, w.vlen); |
There was a problem hiding this comment.
Remove commented code that is not used please.
|
I've got a doubt regarding the labels and features of the FactorGraphMdoel. The labels used for the FactorGraphModel are structured labels where each of them is a FactorGraph, right? Also, the features are a set of FactorGraphs as well? |
|
Could you also maybe paste in here the class diagram that you did for the google doc at the beginning? I think there have been some updates. I find it difficult to keep track of what each class should be doing :) |
|
Sure. I'll draw a new diagram. Now I understand more, and many things have been updated. Let me briefly explain what's going on with FactorGraphFeatures and FactorGraphLabels and FactorGraph. First of all, a sample of FactorGraph is a structured feature, which should be stored in the FactorGraphFeatures (has an array m_samples). By concatenating data in FactorGraph, we get psi, the joint feature map. Here we assume that the FactorGraphModel has a linear parameterization. Then, the FactorGraphLabels store an array of structured outputs, i.e. m_labels. We defined a class FactorGraphObservation for representing the structured output. In our case, a structured output is vector of states (each node in factor graph has a discrete state). So in fact, no structure encoded in the FactorGraphObservation, all structured information are recorded in FactorGraph. |
|
Aham! I understand more about it now. Thank you so much for the detailed explanation! |
|
Updated! However Travis was unhappy about something. |
|
In the current develop I think the RubyModular issue in Travis has already been fixed, so just rebase this branch and force push. |
| @@ -67,7 +67,7 @@ bool CPrimalMosekSOSVM::train_machine(CFeatures* data) | |||
| // Number of auxiliary constraints | |||
| int32_t num_aux_con = m_model->get_num_aux_con(); | |||
| // Number of training examples | |||
| int32_t N = m_model->get_features()->get_num_vectors(); | |||
There was a problem hiding this comment.
Mmm I wonder why this was not causing a memory leak before.
There was a problem hiding this comment.
I guess previous models doesn't hold a DynamicObjectArray for features.
There was a problem hiding this comment.
CStructuredModel::get_features() does
SG_REF(m_features)
How is it related to DynamicObjectArray?
There was a problem hiding this comment.
hmm, m_features is a DynamicObjectArray... m_model->get_features() is my old change from your code, I remember there was a get_features() in StructuredOutputMachine at beginning. But no idea, why no meak leak happens.
There was a problem hiding this comment.
m_features is CFeatures* I think.
There was a problem hiding this comment.
Then, I see the point, for multiclass and hmsvm, features are SGVector or SGMatrix, but in my case, m_features is FactorGraphFeatures, where I hold a DynamicObjectArray for storing FactorGraphs.
|
Changes Unknown when pulling 4244455 on hushell:develop into * on shogun-toolbox:develop*. |
I know this is a huge PR again. Sorry about this. I added 2 classes: FactorGraphModel and FactorGraphFeatures. I tested PrimalMosek solver and BMRM solver, at least the simple example works.
@ppletscher, @iglesias Please help me check the code. For the loss-augmentation, I am not sure it should be in MAPInference or in the model class, it's related to inference, but basically it modifies the energy table.