verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
< JaraxussTong>
I think there is something wrong in range_search_impl.hpp. In some constructor pointer queryTree isn't initialized, once singleMode is true and naive is false, the deconstructor will fail.
< naywhayare>
JaraxussTong: I think you're right; want to submit a PR?
< JaraxussTong>
Yes, I will commit it as soon as possible.
< naywhayare>
thanks!
yingryic has quit [Ping timeout: 264 seconds]
yingryic has joined #mlpack
govg has joined #mlpack
KTL has joined #mlpack
govg has quit [Remote host closed the connection]
KTL has quit [Remote host closed the connection]
govg has joined #mlpack
prafiny has joined #mlpack
< naywhayare>
prafiny: I actually still haven't received my email on how to get icc... maybe I should try again
< prafiny>
Yes why not ! Because it didn't take 1 min for me to receive it :/
< naywhayare>
hm, then I will have to try again L:)
< naywhayare>
(oops, unintended L)
< prafiny>
Hm still some trouble even with icc
< naywhayare>
if you want to paste the output, I can take a look and maybe point you in the right direction
< naywhayare>
JaraxussTong: I'm going to refactor RangeSearch a bit, and that should make it easier to use in MeanShift
< naywhayare>
basically, you'll pass the query set when calling Search(), instead of when calling the constructor
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#41 (master - 0c14444 : Ryan Curtin): The build passed.
< prafiny>
In fact I picked a build of boost for visual and it doesn't seem to deal well with mlpack :/
< naywhayare>
if the boost version is compiled with MSVC, I'm not sure it's guaranteed to work with the intel compiler, so you may have to compile Boost by hand...
< prafiny>
Hm… there must be some prebuilt packages somewhere, mustn't there ?
< naywhayare>
I don't think there can be prebuilt packages, because I don't think you're allowed to distribute anything you build with a free version of icc
govg has joined #mlpack
< prafiny>
Hm i see, and using a mingw build wouldn't help ?
< naywhayare>
using mingw to build boost? I think you might have the same issue as the version built with msvc. but, I'm not certain -- I haven't tried it
< KTL>
i used euclidean distance without normalizing
< naywhayare>
okay, so I think maybe I misunderstand the problem you are trying to solve then?
< KTL>
yes and no, i am building a GMM-implementation but within a larger framework that has less common needs
< KTL>
and without a strong background in math and stats :D
< naywhayare>
yeah, but I still don't get the goal of your proposals, so I can't think about which is the best idea :)
< naywhayare>
could you explain more of what you're trying to do, and what you might like to contribute or see changed upstream?
< KTL>
when i said that i thought it would help to get the random() function more numerically stable ... BUT ... in the meantime i did find a bug in my implementation ...
< KTL>
mmmm but .... that bug ... won't have caused the instability i think ...
< naywhayare>
is Random() unstable? if your Gaussian has positive definite covariance, it should just be drawing randomly from that distribution
< KTL>
i had inf-values on the diagonal of my covlower
< KTL>
and the numerical value of logdetcov could be seriously different depending on the way it was calculated, when the determinant of the covariance matrix was near-zero
< KTL>
one method is to calculate the determinant (with option "std") and take the log
< KTL>
the other method was to take the sum of the logs of the covlower and multiply by 2
< KTL>
anyway, just ignore my rambling, if you ever get numerical issues, a probability that is not between 0 and 1 for example ... then look at it :D
< stephentu>
naywhayare: i was working on LDA on teh plane and i ran into this issue about randomness
< stephentu>
is there any reason we prefer this global random object
< stephentu>
versus threading randomness through the objects
< stephentu>
i implemented LDA doing the latter
< stephentu>
it seems cleaner imo
< naywhayare>
stephentu: no particular reason it was done the way it was originally; can you show me an example of what you mean?
< naywhayare>
KTL: okay, I think I understand
< naywhayare>
I'm fine with forcing "std" for det(), since det() only uses something else if the matrix is 4x4 or smaller
< stephentu>
but you can have hte option of specifying your own
< stephentu>
downside is that everything that takes randomness must be a template
< naywhayare>
one advantage of a global random object is that I can set the seed easily during a test to reproduce a particular bug
< naywhayare>
to me it seems less clear how I might do that with a templated RNG, especially if anything is not using the default RNG
< naywhayare>
a disadvantage of the templated approach is that the API gets more complicated, which I'm not a huge fan of (it's already pretty complex), and also sizeof(Type) is going to get larger by a reference (if you're storing the RNG internally in the class)
< naywhayare>
but I think maybe I am not thinking exactly the same way you are about how this gets implemented
< naywhayare>
and I feel like there are some advantages here I'm overlooking
< stephentu>
naywhayare: 1) sizeof(Type) wont' increase, since you dont store the reference, but just pass it inot hte methods that need it
< stephentu>
the main advantage
< stephentu>
is parallelization
< stephentu>
like if i want to run 20 LDAs in parallel
< stephentu>
i definitely dont want them sharing the same rng
< stephentu>
and i definitely want to run multiple chains in parallel
< stephentu>
thats standard practice for MCMC stuff
< naywhayare>
hang on, I have to step out... I'll be back shortly
< stephentu>
one way to combat api complexity
< stephentu>
is we agree before hand that all random objects in mlpack
< stephentu>
will be say std::default_random_engine
< stephentu>
then we typedef std::default_random_engine rng_t;
< stephentu>
and we use rng_t everywhere
< stephentu>
instead of the template
< naywhayare>
stephentu: sorry for the delay... I think this is a good idea, because parallelism is a nightmare otherwise
< naywhayare>
I think the extra API bloat of having template parameters for functions that use RNGs is unfortunate, but somewhat unavoidable
< naywhayare>
providing default arguments and good documentation is probably a decent solution here
< naywhayare>
so, we should figure out how to make the doxygen output look a bit nicer for functions that have a crapload of parameters and template arguments (maybe, optionally hide all the parameters that have default arguments or something)
< naywhayare>
but that can happen another day
< naywhayare>
the typedef rng_t solution has problems (if you are trying to let the user overload it) if rng_t is ever used in a .cpp file somewhere, and the user selects something other than default_random_engine