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/
xiaohong has joined #mlpack
xiaohong has quit [Remote host closed the connection]
xiaohong has joined #mlpack
xiaohong has quit [Ping timeout: 252 seconds]
xiaohong has joined #mlpack
mlpackuser100 has joined #mlpack
pd09041999 has joined #mlpack
xiaohong has quit [Ping timeout: 248 seconds]
pd09041999 has quit [Ping timeout: 258 seconds]
travis-ci has joined #mlpack
< travis-ci>
mlpack/ensmallen#304 (ensmallen-1.15.1 - 8bea8d2 : Ryan Curtin): The build passed.
< rajs123>
Hi, I wanted to know what is process of contributing to mlpack in structure similar to gsoc projects [identify projects and contribute intensively for 3-4 months] without getting enrolled in gsoc. I come from trading background with lots of C++ exp, and have been deeply involved in ML for last few years.
< jeffin143>
rcurtin : When are we going to have our sponsor button setup :)
< rcurtin>
jeffin143: I think we should successfully join NumFOCUS first :) but we can keep that process moving, I think there is not too much left to do
< jeffin143>
:)
favre49 has joined #mlpack
< favre49>
rcurtin: It seems the random forest test can fail sometimes.
< rcurtin>
favre49: I think it hit the 90 minute build limit---let me restart it and let's see what happens
< favre49>
I'll be pushing a commit for the style fixes, no need to restart yourself :)
< favre49>
thanks for your help!
< rcurtin>
ah, ok, yeah, I don't see a restart button anyway :)
jeffin143_ has joined #mlpack
< jeffin143_>
lozhnikov , rcurtin , zoq : is it ok to user unordered_map<const char* , int> in mlpack ?
< jeffin143_>
because i read release mails and in mlpack 2 all char* were replaced by string . !
< rcurtin>
jeffin143_: that was mostly for user-facing APIs. I think in your case you are looking to have a map using a substring as a key?
< rcurtin>
so long as that's 'safe' (i.e. std::string gives a guarantee that it internally holds a const char* that you can use in that way), I don't personally see a problem with it
< lozhnikov>
jeffin143_: No, that won't work for equal strings if the pointers are different.
< rcurtin>
others may have different input :)
< jeffin143_>
lozhnikov : token.data()
< rcurtin>
lozhnikov: could you use strcmp() as the unordered_map<> equality function?
< rcurtin>
strncmp() I guess for safety :)
< rcurtin>
only problem is, then the type starts to get really ugly...
< lozhnikov>
I suggest to introduce a database e.g. std::vector<std::string> and a map std::unordered_map<boost::string_view, size_t>
< jeffin143_>
if if declare unordered_map<boost::string_view,size_t> , all the member function doesn't work , find() or count()
< lozhnikov>
jeffin143_: hmmm... I didn't know. Why?
< jeffin143_>
so i the solution i had in my mind was to declare unordered_map<const char* , int> and then use boost::String_view.data() member function which return a pointer and the char array is saved
favre49 has quit [Quit: Page closed]
< jeffin143_>
but you are right
< jeffin143_>
throws a segmentation fault since the pointers are different when i use the same variable.
< lozhnikov>
jeffin143_: I tried to investigate why unordered_map doesn't work with boost::string_view. Looks like we need to define the hasher.
< jeffin143_>
i also tried, had glance over some of the stack overflow post, but didnt't find a convencing one
< jeffin143_>
hashed as in ?
< jeffin143_>
hasher*
< lozhnikov>
Did you try std::unordered_map<boost::string_view, int, boost::hash<boost::string_view>> ?
< jeffin143_>
No, I didn't . Give me a moment i will try that out
< lozhnikov>
rcurtin: In case of strncmp() as the key equality function. We need to pass the length of the substring somehow. That leads us to something like string_view.
< rcurtin>
lozhnikov: yeah, I was thinking about what I wrote and you're right. It seems like string_view is the best option here
< rcurtin>
(my only concern is added overhead for the inclusion of more boost headers, but perhaps string_view is lightweight---and if not, there are ways to mitigate the problem)
< lozhnikov>
rcurtin: yeah, string_view is pretty small
govg has joined #mlpack
< jeffin143_>
lozhnikov : no it throws up several error, tried debugging it , but couldn't
< jeffin143_>
for some reason they don't have support for string_view, i mean boost::hash