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/
govg has joined #mlpack
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
alexsc has joined #mlpack
alexsc has quit [Quit: alexsc]
alexsc has joined #mlpack
alexscc has joined #mlpack
alexscc has quit [Quit: alexscc]
vivekp has quit [Ping timeout: 240 seconds]
vivekp has joined #mlpack
< alexsc> rcurtin: went for the argmax, 4 lines in armadillo. let me know if I shall integrate it somewhere!
< alexsc> + my implementation of KNN gives the choice of weighting window among the K neighbors.. rectangular (same weight to all K), triangular, and so on
< alexsc> is there any way to achieve this currently in mlpack?
< alexsc> I can answer myself.. nope :). I’ll code it
< rcurtin> alexsc: yeah, unfortunately, there is not an existing way to do that
< rcurtin> if you implement it, though, it would be great to include the functionality, I would be happy to work with you on a PR to get it merged in
< alexsc> would you see it as a template arg?
< rcurtin> since we have so many techniques that are related to nearest neighbor search, I'd personally think it should be a standalone function that you put your neighbors/distances results into
< alexsc> enum KNNWeightingKernelType {
< alexsc> kRectangular = 0, // 0.5 · I(|d| ≤ 1)
< alexsc> kTriangular, // (1 − |d|) · I(|d| ≤ 1)
< alexsc> kEpanechnikov, // 0.75 * (1 − d^2 ) · I(|d| ≤ 1)
< alexsc> kQuartic, // 15/16 * (1 − d^2)^2 · I(|d| ≤ 1)
< alexsc> kInversion // 1 / |d|
< alexsc> };
< rcurtin> alternately, if you want to do something more complex, I think you could make a class like
< alexsc> would be worth it, normally accuracies are so much better with Triangular windows
< rcurtin> class KNNClassifier<template KNNSearchType>
< rcurtin> and then inside of that KNNClassifier class, you would just call KNNSearchType(k, neighbors, distances) and then use KNNWeightingKernelType to figure out the labels
< rcurtin> this would be a really nice contribution if you were willing to take the time :) (and one that probably should have been done years ago... I'm sorry the support you need isn't already there)
< alexsc> cool, will do it beginning of the next week… I have a deadline on friday
< rcurtin> sounds great, and let me know how I can help out if you need. good luck with the deadline :)
< alexsc> sure, thanks for now!
< alexsc> that NCA is making wonders… +30% accuracy over untreated KNN
govg has quit [Ping timeout: 260 seconds]
< alexsc> question: sorry for bothering today
< alexsc> I compiling my KNN on mac is ok. now on Ubuntu, installed with apt-get, I am getting index_max not a member of arma in RcppArmadillo
< alexsc> sorry, bad paste from stackoverflow: I get arma::uvec {aka class arma::Col<long long unsigned int>}’ has no member named ‘index_max’
< alexsc> do you know how to update armadillo to a more current version?
govg has joined #mlpack
< alexsc> k. built from source :)
< rcurtin> oops, sorry, stepped out for a few minutes
< rcurtin> index_max() is available from 7.300 onwards, so in ubuntu 14.04 or 16.04 the version is too old
< rcurtin> so yeah, compiling from source is probably the best option
alexscc has joined #mlpack
killer_bee[m] has joined #mlpack
alexsc has quit [Ping timeout: 248 seconds]
alexsc has joined #mlpack
alexscc has quit [Quit: alexscc]
alexscc has joined #mlpack
alexscc has quit [Quit: alexscc]
alexsc has quit [Quit: alexsc]
< zoq> rcurtin: Having fun with #1125 and travis.
< rcurtin> I wouldn't call it fun... :)
< rcurtin> I'm flabbergasted first that ubuntu 16.04 has a background auto-update process, and second that the travis images don't automatically disable it and prevent it from running
< rcurtin> I think that even though I run 'systemd stop apt-daily.service apt-daily.timer', the process has already started by then and continues, so I may have to find some other way to kill it or prevent it from starting...
< zoq> hmm, I am confident that you solve the issue
< rcurtin> yeah... I don't know how long it will take though...
< rcurtin> I think I will have to find the travis-ci docker images and run them directly, but I haven't taken that step yet
< rcurtin> really I would rather be writing code instead of debugging CI tools :)
< rcurtin> but such is the nature of CI :)
< zoq> We don't use the travis docker container, we use the VM on GCE, the last time I checked running on GCE was way faster; besides GCE provides 7.5GB of RAM instead of 4GB.
< rcurtin> ah, ok; I hadn't looked into it much
< rcurtin> I do suspect there may exist a docker container with the exact same configuration as GCE, but let's see what this round of debugging brings back before I look into that...
< zoq> right, maybe there is an docker image