ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
jenkins-mlpack2 has quit [Ping timeout: 240 seconds]
< khizirsiddiqui>
Hey! I am working this issue to output class probabilities for test point using adaboost. I am not able to add CLI support for it. If I am not mistaken adaboost_main.cpp handles the CLI part, I have added PARAM_MATRIX_OUT("predict_proba", ...... ) with other output cli args. mlpack_adaboost complies good but it doesn't recognize predict_proba as a
< khizirsiddiqui>
valid argument on usage.
< khizirsiddiqui>
what am I missing here?
< khizirsiddiqui>
Also, I couldn't find how the --help arg outputs optional args.
< khizirsiddiqui>
Thanks for help. :)
adityaviki has joined #mlpack
khizirsiddiqui has quit [Ping timeout: 260 seconds]
adityaviki has quit [Ping timeout: 260 seconds]
< rcurtin>
khizirsiddiqui: that seems strange, can you provide the exact code that you added?
< khizirsiddiqui>
i changed my directory to build. then-> cmake ../ && sudo make -j4 mlpack_adaboost
< rcurtin>
mlpack_adaboost gets built into the build/bin/ directory
< rcurtin>
when you run `$ mlpack_adaboost`, have you manually added build/bin/ to your PATH environment variable?
< rcurtin>
i.e., are you sure that the mlpack_adaboost program you are calling is the correct one?
< rcurtin>
if you are just typing `$ mlpack_adaboost`, you can see which one is being called with `which mlpack_adaboost`
< khizirsiddiqui>
:| yeah, i was doing it wrong.
< khizirsiddiqui>
Now i've added build/bin to path, and now getting this error:
< khizirsiddiqui>
```mlpack_adaboost: symbol lookup error: mlpack_adaboost: undefined symbol: _ZN6mlpack8adaboost13AdaBoostModel12PredictProbaERKN4arma3MatIdEERNS2_3RowImEERS4_```
< khizirsiddiqui>
on calling `mlpack_adaboost --help`
< rcurtin>
okay, now you have library versioning problems
< rcurtin>
I know what's happening here so I'll just explain it, and you can verify if what I said is right
< rcurtin>
earlier, I imagine you installed mlpack either with 'make install' or 'apt-get install libmlpack-bin' or something like that
< rcurtin>
that means that there's now a libmlpack.so in either /usr/lib/ or /usr/local/lib/ depending on whether you used apt or installed from source
< rcurtin>
now that you've added mlpack_adaboost to your PATH, it's going to try to use that libmlpack.so that is in /usr/lib/ or /usr/local/lib/
< rcurtin>
but that is an old version and doesn't have the functionality that you added
khizirsiddiqui has quit [Ping timeout: 260 seconds]
< rcurtin>
so, I think, you could run mlpack_adaboost directly with just `$ bin/mlpack_adaboost ...`, or, you can set LD_LIBRARY_PATH to `build/lib/` so that hopefully it gets the right one
khizirsiddiqui has joined #mlpack
< khizirsiddiqui>
Oh! I get it, ok ok.
< khizirsiddiqui>
I've exported `LD_LIBRARY_PATH` as `build\lib` and it works now. thanks!
< zoq>
This isn't the first time, so perhaps it makes sense to print out some information during the cmake step?
< khizirsiddiqui>
zoq: can we add something like this on github readme?
< zoq>
khizirsiddi: Hm, I guess there are multiple options where we can put this, personally I would put it into the build tutorial, write a new section about pitfalls.
< zoq>
I guess if we put it into the cmake file itself we could print out a message if we detect another mlpack version, and either provide a simple solution or link to some document.
< zoq>
Also, I like the README.md idea and this is great to have, especially if you ship the tarball, but perhaps we should clear the README.md file in favor of the install instructions tutorial.
< rcurtin>
if you build `mlpack_adaboost` in the build directory it should be RPATH-linked directory to build/lib/libmlpack.so
< rcurtin>
so if you just ran bin/mlpack_adaboost without changing $PATH or $LD_LIBRARY_PATH I *think* that should work... correct me if you find otherwise
khizirsiddiqui has quit [Ping timeout: 260 seconds]