Open hushell opened 10 years ago
@hushell how should the loading/saving of graphs work, could you elaborate a bit?
Hi, I have some experience with graphical models so I thought I would work on this issue. I am finished with 4, 8 and fully connected graphs. I am unsure what would be better in graph loading and saving. If we load/save graphs from sources like uai files, independent functions would be better. Serialization would limit the format of graphs we can load from. What do you think ?
@aroma123 and @karlnapf : I was thinking just save/load the CFactorGraph, but it will be nice if we are compatible with UAI format. @aroma123 : try to reuse Sontag's MPLP code: http://cs.nyu.edu/~dsontag/code/README_v2.html if you decided to go with UAI format.
@aroma123 BTW, if you have time, you may also want to work on this: https://github.com/shogun-toolbox/shogun/issues/1916, I think @tklein23 will be happy to be involved :)
@hushell i cannot agree with CFactorGraphFile
. why dont we create an CUAIFile
class that can handle UAI
file in general, i.e. define all the right data structures and APIs and then when we have that ready, create maybe a CFactorGraphFile
UAI has the following syntax:
<Preamble>
<Function tables>
so in other words we need to define a function in CUAIFile
that can parse any <Preamble>
and then another function that can read the <Function tables>
based on the preamble information.
and then of course define the API in CUAIFile
that supports reading these information...
@hushell same goes for CFactorGraph::convert_to_UAI(CFactorGraphFile* file, CFactorGraphFile* uai_file)
... why would you have a file formatting/conversion function in CFactorGraph
?
it's purely IO related story.... it's like you would put csv
to libsvm
format conversion in LibSVM
... why?
@vigsterkr and @hushell : What I understood from the discussion above that:
CUAIFile
. Once this class is ready with all its API, then CFactorGraphFile
should be created that would inherit from CUAIFile
. (correct me if I am going in wrong direction).CFactorGraph::convert_to_UAI(CFactorGraphFile* file, CFactorGraphFile* uai_file)
, we could be overloading the CFactorGraph::save
method. CFactorGraph::save(CUAIFile* file)
would save the graph in UAI file format and CFactorGraph::save(CFactorGraph* file)
would save the graph in FactorGraph file format.@abinashpanda, as I understood it, there would be no CFactorGraphFile, because you may want to read UAI files and not necessarily use them for factor graphs.
Have a look in the examples to how CSVFile is used. CUAIFile should be used in a similar manner, just parsing UAI files instead of CSV files.
I have another idea. Why do we need to have different classes for different format. Can't we just have multiple functions for CFactorgraph class itself like CFactorgraph::load_from_uai , CFactorgraph::save_to_uai ? This way we can add support for other file formats later. What do you think ?
@aroma123 in short: not a good idea
@aroma123, so say that tomorrow I make a Markov network class in Shogun and I want to be able to load Markov networks from UAI files. Then I should make CMarkovNetwork::load_from_uai, CMarkovNetwork::save_to_uai which are going to be pretty much the same as CFactorGraph::load_from_uai and its brother.
See the point?
Okay. Also, I was looking at code @hushell pointed to reuse for uai for implementation. How should .evid files be handled ?
@aroma123 let's concentrate on UAI itself now... but either it'll have to be a part of CUAIFile
or a separate class. although since they are related they should be somehow coupled.. same goes for result file...
@vigsterkr So a virtual function for loading evidence should do for now ?
@aroma123 i'm not so sure if i understand the direct connection between a virtual function and an unimplemented functionality... as said earlier let's concentrate first on UAI itself.
Understood. Working on it. Get back soon.
@aroma123 and @abinashpanda: Please read my updated description!
@hushell this design pattern is completely flawed
void CUAIFile::save(CFactorGraph* fg);
it should be CFactorGraph::save(CUAIFile*)
and CUAIFile
should have interim variables to represent an uai
file...
@vigsterkr Thanks for pointing this out. I was not familiar with IO part at that time. Now I find the correct way, an example is void SGVector::save(CFile* saver)
. I'll update the description right away :)
Hey @hushell, @abinashpanda , did the part CFactorGraph::save(CUAIFile*)
finally happen? I see the CUAIFile implementation but no how it can be used from FactorGraph.
@iglesias Finally Throlf and I decided to let Abinash focus on multilabel classification. So this final step to make use of CUAIFile hasn't been done yet. Maybe @Jiaolong want to continue on this :) Anyway, If he doesn't have time, I'll do it in June. Now I am overwhelmed by homeworks and projects.
@hushell I am currently focusing on MPLP and Graph cut. I will take a look at this issue. Also, I would like to compare it with OpenGM which employs HD5 for reading and saving graphical model.
This is an entrance task for this project: http://www.shogun-toolbox.org/page/Events/gsoc2014_ideas#sosvmapprox
Currently, no approximate inference implemented with factor graph model in Shogun. This is what we are going to do this summer. In the first step, we could create graphs with loops for later use.
CUAIFile
. A reference of loading function is here: http://cs.nyu.edu/~dsontag/code/README_v2.html. Note that function tables can be computed byCFactorGraph::compute_energies()
, and obtained bySGVector<float64_t> CFactor::get_energies() const
. Add member functionsCFactorGraph::save(CUAIFile*)
andCFactorGraph::load(CUAIFile*)
, whereCUAIFile
should have interim variables to represent an UAI file (according to Viktor's suggestion). To support the loading function, you need to set energy table for each factor. Make sure that you really understandCFactor, CFactorType, CFactorGraph
.