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/
ib07 has quit [Remote host closed the connection]
ib07 has joined #mlpack
ib07 has quit [Ping timeout: 256 seconds]
< AakashkaushikGit> Do the `ensmallen` library contain a version constant such as `armadillo` does ?
< zoq> AakashkaushikGit: yes - ens::version::as_string()
< rcurtin> ENS_VERSION_MAJOR, ENS_VERSION_MINOR, and ENS_VERSION_PATCH should all be available too if you're looking for preprocessor constants
< rcurtin> zoq: beat me to it :-D
< AakashkaushikGit> Thanks @rcurtin and @zoq , i was looking for it in `ensmallen.hpp` also should i use this version number to check if ensmallen is the required version in mlpack/examples, i was thinking about this approach.
< AakashkaushikGit> What do you guys think ?
< rcurtin> sure, that could be a way to do it; I don't think there's a CMake configuration in mlpack/examples (correct me if I'm wrong), so simply doing a preprocessor macro check could work
< rcurtin> maybe some other people have different opinions though---I haven't been able to keep up with the examples repo as much as I would like to
< zoq> yes, we don't use CMake in the examples repo.
< AakashkaushikGit> yup was writing the same :D
< zoq> a macro check sounds good to me
< AakashkaushikGit> so should i go ahead a create a PR for the examples that require a certain version ?
< zoq> sounds like a good plan to me
< AakashkaushikGit> Great
ib07 has joined #mlpack
ib07 has quit [Ping timeout: 256 seconds]
< rcurtin> jeffin143[m]: you are a machine with all those test conversions! :-D
zoq has quit [Ping timeout: 240 seconds]
zoq has joined #mlpack
< jeffin143[m]> > jeffin143: you are a machine with all those test conversions! :-D
< jeffin143[m]> Hehe 😂
< CharanpreetSingh> After building mlpack ( through vcpkg ) , I tried running the Sample-ml-app (https://www.mlpack.org/doc/mlpack-3.4.1/doxygen/sample_ml_app.html) but getting following errors : (https://drive.google.com/drive/folders/1EAZm1AUmzjQv5Krg1fr4eaMHB_S0K11K?usp=sharing)
< CharanpreetSingh> upon building mlpack ( through vcpkg ) , I tried building and running the sample-ml-app (https://www.mlpack.org/doc/mlpack-3.4.1/doxygen/sample_ml_app.html) but it was not able to load the dataset (although it was built successfully). Here (https://drive.google.com/drive/u/1/folders/1EAZm1AUmzjQv5Krg1fr4eaMHB_S0K11K) is the code and its output.
ib07 has joined #mlpack
ib07 has quit [Ping timeout: 272 seconds]
< AakashkaushikGit> Do you have the diabetes.csv in place ?
< shrit[m]> from /meta/mlpack/build/src/mlpack/cotire/mlpack_CXX_prefix.hxx:4:
< shrit[m]> from /meta/mlpack/build/src/mlpack/cotire/mlpack_CXX_prefix.cxx:4,
< shrit[m]> from /meta/mlpack/src/mlpack/prereqs.hpp:102,
< shrit[m]> In file included from /meta/mlpack/src/mlpack/core/cereal/pointer_variant_wrapper.hpp:25,
< shrit[m]> [ 0%] Building CXX object src/mlpack/CMakeFiles/mlpack.dir/methods/hoeffding_trees/hoeffding_tree_model.cpp.o
< shrit[m]> /meta/mlpack/src/mlpack/methods/hoeffding_trees/hoeffding_tree_impl.hpp: In member function ‘void mlpack::tree::HoeffdingTree<FitnessFunction, NumericSplitType, CategoricalSplitType>::serialize(Archive&, uint32_t)’:
< shrit[m]> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
< shrit[m]> 807 | ar(CEREAL_POINTER(const_cast<data::DatasetInfo>(datasetInfo)));
< shrit[m]> /meta/mlpack/src/mlpack/methods/hoeffding_trees/hoeffding_tree_impl.hpp:807:21: error: cannot bind non-const lvalue reference of type ‘mlpack::data::DatasetMapper<mlpack::data::IncrementPolicy>&’ to an rvalue of type ‘mlpack::data::DatasetInfo’ {aka ‘mlpack::data::DatasetMapper<mlpack::data::IncrementPolicy>’}
< shrit[m]> /meta/mlpack/src/mlpack/core/cereal/pointer_wrapper.hpp:96:48: note: in definition of macro ‘CEREAL_POINTER’
< shrit[m]> @rcurtin this is the error I am getting after building locally.
< shrit[m]> Maybe we need to keep only this one as it was?
< shrit[m]> I think we need to keep the lvalue in this case as CEREAL_POITER takes a non const reference,
< rcurtin> I think you need that const_cast to be a pointer: const_cast<data::DatasetInfo*>
< rcurtin> just guessing, maybe that's not it
< shrit[m]> Maybe, I will give it a try
< shrit[m]> It is already a pointer, this is my terminal error, either copying or pasting :D
< shrit[m]> Also I am on weechat so, I do not know how it handle the sepcial chars
< shrit[m]> special
< shrit[m]> Even other are causing this error, the issue is that since CEREAL do not take a const pointer, it will not be possible to pass a temporary variable that is resulted from the cast, we need a named variable in this case. I am not sure, I am not expert.
< shrit[m]> CEREAL_POINTER
< rcurtin> I don't understand what the problem is
< rcurtin> can you clarify what the code that produces the problem is?
< rcurtin> the error you gave seems to suggest that there is no * in the const_cast, but I am not sure
< shrit[m]> I will paste the error into github, it will clear there.
< rcurtin> ok, sounds good
< rcurtin> shrit[m]: maybe const_cast<DatasetInfo*&>?
< rcurtin> if it is a reference type being passed in you will need to preserve the reference in the const_cast
< abernauer[m]> I need to get back on that PR tomorrow.
< shrit[m]> @rcurtin the & seems to be working
< shrit[m]> thanks
< rcurtin> sure, happy to help---glad that solved the issue :)
< shrit[m]> Still do not understand why it did work
< rcurtin> pointers are passed by copy---so this code, for instance, will not behave as expected:
< rcurtin> int x = 10;
< rcurtin> int* y = &x;
< rcurtin> int z = 20;
< rcurtin> void modify_ptr(int* v) { v = &z; }
< rcurtin> modify_ptr(y);
< rcurtin> after this code runs, if I were to do:
< rcurtin> std::cout << *y << std::endl;
< rcurtin> that would not print 20 (the value of z); it would print 10 (the value of x)
< rcurtin> this is because when I call modify_ptr(y), the pointer y is copied, and so the line `v = &z;` in the function body actually is only working on a temporary v, not on the value of y!
< rcurtin> if we wanted to modify where the pointer points, we would have to pass either a pointer to y, or a reference to y, like this:
< rcurtin> void modify_ptr_correct(int*& v) { v = &z; }
< rcurtin> and *that* function would behave as expected
< rcurtin> so, in the case of CEREAL_POINTER(), since the pointer wrapper needs to modify a pointer, it has to take a T*&, not a T*; if we only gave it a T*, it would just copy the pointer and have no effect on whatever we were serializing
< rcurtin> I hope that makes sense, but maybe there are other resources out there than my rambling that do a better job of describing the issue :)