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/
Mulx10 has joined #mlpack
< Mulx10>
sreenik, gmanlan, jeffin143, zoq, rcurtin : using '#ifdef OPENCV_INSTALLED' is a good idea.
< Mulx10>
Also, I don't understand what you mean by OpenCv converter?
< Mulx10>
However, if introduction of optional dependency is fine, I shall go ahead with it.
< rcurtin>
Mulx10: I mean that if there is already some way, without implementing a special function, to load data in OpenCV and then convert it to arma::mat, then there is no need for us to implement a function
Mulx10 has quit [Ping timeout: 256 seconds]
petris_ is now known as petris
gmanlan has joined #mlpack
< gmanlan>
rcurtin: you there?
< rcurtin>
yeah, I am finishing debugging these random forest changes
< rcurtin>
I of course introduced some bug that's really irritating to track down
< rcurtin>
I wanted to take the night off after I got it working, but now it's 10:30pm and no end in sight...
< gmanlan>
oh, I'm sorry to hear that
< rcurtin>
"nothing can be simple" :)
< gmanlan>
anything I can do to help?
< rcurtin>
on the up side, I improved the implementation's speed by orders of magnitude in some cases
< gmanlan>
oh that's awesome!
< rcurtin>
nah, I feel like I am close
< rcurtin>
I also ended up adding a few more parameters to the random_forest binding
< gmanlan>
that's great
< gmanlan>
ok, so to cheer you up, I made some progress with the python bindings on windows
< rcurtin>
so I'm happy I took the time to fix this. the implementation still isn't as good as it could possibly be, but it seems to be faster than scikit in many cases (in part because it is easily parallel)
< rcurtin>
great to hear!
< gmanlan>
(faster than scikit makes me so happy)
< gmanlan>
I will be adding my findings tomorrow to the python binding issue we were working on, but may need your guidance on how to change a couple of cmakes
< rcurtin>
like I said, I know there's more there. but I don't have the time at the moment to accelerate it further
< rcurtin>
sure, I'll try to help while I'm waiting for things to compile :)
< gmanlan>
and to continue with the news... I have started working on an entirely new website
< gmanlan>
based on what we discussed last time via email
< rcurtin>
that sounds good, is your plan to use the existing website as a base?
< rcurtin>
I would imagine it's mostly just new content that needs to be dropped into place
< rcurtin>
but I'm not totally sure what you had in mind
< gmanlan>
yes, I'm keeping the current jekyll site, but heavily customized
< gmanlan>
I'm trying to bring material and flat design to the website
< gmanlan>
putting a lot of emphasis on the landing experience (i.e. getting started, multiple download/build options, etc)
< rcurtin>
that sounds great
< gmanlan>
I will be sharing some previews with you soon
< rcurtin>
I am a completely incompetent web developer so I am sure what you will come out with is way better :)
< gmanlan>
:) you did a great job, I'm just trying to bring mlpack to a TensorFlow level of website
< rcurtin>
even the template we have now is taken from the ensmallen website, which was itself taken from the armadillo website...
< rcurtin>
I think my websites are optimized for people who are trying to pretend they still live in the 90s, like myself :)
< gmanlan>
hahahahaa
< gmanlan>
yeah, the template is somehow basic and there are no suitable templates out there, so I'm keeping it as a base but adding many customizations (which I hope will not be hard to maintain)
< jeffin143>
Wonderful
< jeffin143>
To head it gmanlan :)
< gmanlan>
I don't really expect we would be changing the landing page/getting started sections too often
< gmanlan>
:)
< jeffin143>
Hear*
< rcurtin>
yeah, definitely not, mostly I just need to be able to use sed/awk scripts to update the versions of links, etc.
< rcurtin>
but that should be no problem at all
< gmanlan>
coolo - I'm a little bit of a perfectionist so I will take my time, but bear with me
< gmanlan>
*cool
< rcurtin>
if it's finally time to transition to a black-on-white theme I'm okay with that too
< rcurtin>
I know the feeling---take your time :)
< jeffin143>
No , white on black suits much better , there are lot black on white, we can be unique
< jeffin143>
May be we could vote for that :)
< gmanlan>
haha, well it depends on the goal
< gmanlan>
if we want to increase adoption from users such as 'the industry' then it's better to be more 'serious'
< rcurtin>
sounds fine to me. I do think the white-on-black is a distinctive thing, but I don't know how easy it would be to accomplish gmanlan's goals like that
< rcurtin>
maybe a less "extreme" light-on-dark can do the job, not sure?
< gmanlan>
I have some UX friends
< gmanlan>
I can ask around for advice
< rcurtin>
:+1:
< rcurtin>
or I guess I should actually go dig up the right Unicode character... 👍
< rcurtin>
(not that it displays in my terminal. I just see a black box)
< gmanlan>
haha, it looks great
< rcurtin>
yeah, I checked the IRC log page to make sure it went through :)
< gmanlan>
rcurtin: are you tagging/saving the .msi files for each release?
< gmanlan>
or better said, the artifacts in general?
< rcurtin>
I think AppVeyor builds them but I don't currently have a process to grab or tag them
< rcurtin>
it should be easy enough to get them, since I think AppVeyor will build the tags too
< gmanlan>
ah ok, we will need that - AppVeyor deletes the stuff after a while
< rcurtin>
oh, let me see if I can quickly get a copy of the 3.1.0 tag one then
< gmanlan>
we may need to add it in /files like the .tars
< rcurtin>
yeah, I think so. not sure exactly how to automate it yet, but we can figure that out later
< gmanlan>
(Y)
< gmanlan>
👍
< rcurtin>
only thing is, I'm not totally sure that installer works
< rcurtin>
it doesn't seem to want to start in wine, but that's probably wine being broken
< gmanlan>
I tested the .msi from your RF PR and it worked just fine
< rcurtin>
ok, let me update the website then
< rcurtin>
it's a different msi but probably works fine
< rcurtin>
gmanlan: ok, finally, that took way longer than I had hoped. I'm headed to bed now; I think the RF fix is done now (at least for now... hopefully it works right for you :))
< gmanlan>
fantastic rcurtin
< gmanlan>
I will test it first thing tomorrow
< gmanlan>
thanks for all your help!
< rcurtin>
sure, I should have avoided writing the bug in the first place :)
< gmanlan>
:)
< jeffin143>
gmanlan : seems you are very good with windows os , :-p I am much better of with Linux
gmanlan has quit [Ping timeout: 256 seconds]
Mulx10 has joined #mlpack
< Mulx10>
rcurtin : loading images followed by conversion to arma::mat is possible
< ShikharJ>
saksham189: Toshal: Okay, tomorrow after 9pm sounds good.
< rcurtin>
favre49: thanks, I'll see if I can find that bit and fix it tonight
favre49 has quit [Quit: Page closed]
pd09041999 has quit [Ping timeout: 245 seconds]
< gmanlan>
rcurtin: I'm still testing the changes you pushed for RF - one question: is it possible to control tree depth in the current implementation? If not, what's the criteria being used?
pd09041999 has joined #mlpack
< rcurtin>
gmanlan: we haven't implemented any support for tracking depth in the tree building procedure, but I don't think it would be particularly hard
pd09041999 has quit [Quit: pd09041999]
< gmanlan>
ok - I guess it would be a good addition to prevent overfiting when playing with large datasets, I will add a personal note so we consider it in the future
< saksham189>
ShikharJ: Ok, let's have it then.
< rcurtin>
I dunno, I think also minimum_leaf_size is a (roughly) equivalent way to prevent overfitting, but I can agree, it could be nice to add in the future
< gmanlan>
that's the thing, unfortunately I'm not an expert but I'm trying to help move some implementations from other frameworks such as sci-kit, and because parameters don't match 100%, users go into panic mode
< gmanlan>
it's not necessarily an mlpack problem though - it's a knowledge problem :)
< rcurtin>
gmanlan: yeah, you're right about that, which would be a good reason to also include a max depth parameter
< rcurtin>
I thought about it for a while, the two things are somewhat different ways of regularizing the tree
< rcurtin>
in practice they probably *usually* perform about the same, but not necessarily
< gmanlan>
rcurtin: yes - thanks for sharing your thoughts. I wish I could have more experience on the tuning area, hopefully soon
preacher_ has joined #mlpack
< preacher_>
hello
preacher_ has quit [Client Quit]
< rcurtin>
gmanlan: no problem, even if we add more parameters one could use the hyperparameter tuner to find the best ones :)
< rcurtin>
the hyperparameter tuner is really a cool piece of code; however, it's currently not very discoverable
< rcurtin>
we have a tutorial, but I don't think it makes it very easy to use
< gmanlan>
oh, well, I didn't know we have one (I suspected it)
KimSangYeon-DGU has quit [Ping timeout: 256 seconds]