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/
benchmark has joined #mlpack
benchmark has quit [Client Quit]
< zoq>
some nice speedups
< rcurtin>
yeah, I am trying to think of why those speedups might be, but I am not sure
< rcurtin>
I guess possibly it is the modifications to the pruning rules marcos implemented some time back
tham has joined #mlpack
< tham>
Finished the prototype of iterative pca, but the speed are not as fast as the paper said
< tham>
I think I do not implement this algorithm properly
< tham>
I do not check the converge condition by trans(eigvec) * eigvec - 1
< tham>
because they never converge as the paper said, I guess there must be something wrong about my implementatin
< tham>
keonkim : maybe we could set the parameter as string
< tham>
and parse it by regular expression
< tham>
this way you would be able to input several parameters at once
< tham>
ask the users to input the params as [1,2,3,4]
< tham>
or "1,2,3,4"
< tham>
regex("\[(\\d+,)*(\\d+)?\] | ")
< tham>
good news is c++11 provide as regex library already
< keonkim>
tham: should I go for fixing PARAM_VECTOR or REGEX?
< tham>
keonkim : Not sure
< tham>
I would prefer regex in this case since param vector are rarely use
tham has quit [Ping timeout: 250 seconds]
Mathnerd314 has quit [Ping timeout: 240 seconds]
mentekid has joined #mlpack
nilay has joined #mlpack
mentekid has quit [Ping timeout: 258 seconds]
tham has joined #mlpack
nilay has quit [Ping timeout: 250 seconds]
mentekid has joined #mlpack
tham has quit [Quit: Page closed]
nilay has joined #mlpack
< nilay>
zoq: Hi, i was able to compile the file separately but now when I add the layer file and compile, i added the name in CMakeLists.txt in layer/, do we need to add anything else?
nilay has quit [Ping timeout: 250 seconds]
< zoq>
nilay: Adding the file to CMakeLists.txt should be enough. What's the error?
nilay has joined #mlpack
< nilay>
zoq: there is no error it simply skips the file
< nilay>
the file does not compile
< zoq>
If you include the inception layer header file in one of the test, it doesn't return an error?
nilay has quit [Ping timeout: 250 seconds]
nilay has joined #mlpack
< nilay>
when i include in test it shows errors, but when i don't include in tests, it doesn't compile it
< zoq>
Maybe because it's unused it's skips the file.
< zoq>
What's the error?
< nilay>
yeah that was happening. i can figure the errors, they are mainly namespace errors
< zoq>
okay
< nilay>
we don't want a hardcoded inception layer right?
< zoq>
No, but I guess, the only thing you can modify is the number of input and output filter?
< nilay>
don't run it right now, it has lot of namespace error, but do you agree with the comment at the top
< nilay>
can we do something like that
< nilay>
i get this idea after i understood template recursion
< zoq>
do you mean we constrcut the inception layer or the inception network with (conv1, bias1, base1- concat with - ...?
< nilay>
yes
< nilay>
i make a generic sublayer class
< zoq>
for the network or the layer?
< nilay>
subnetworklayer class
< nilay>
which does forward backward gradient updates
< zoq>
so I guess, for the network part
< nilay>
and also one concatenation_layer class, which will just concatenate outputs, in forward and distribute for the backward
< zoq>
yeah, right we definitely need a concat layer.
< nilay>
if we can make a subnetwork class it would be easier to stack repeating components (like inception layer)
< nilay>
otherwise write separate hard coded inception layer for each type of repeating subnet
< zoq>
yeah, good idea
< nilay>
same cnn.hpp functions are required but as you said, we cannot construct a net, so we use those functions in layers
< zoq>
what I don't get is, how can the number of output filter for the conv1 layer be different from the conv3 layer?
< zoq>
How can we accumulate the output of different sizes, maybe I missed something?
< nilay>
i have to check
< nilay>
give me a minute
< zoq>
Maybe it becomes clear if I see the test for the forward pass.
< nilay>
ok, should i do it first, or do you think i implement the subnet_layer class
< zoq>
I think it's better to implement the test first, so that we can make sure, the forward and backward pass works.
< nilay>
do you see the table they made in paper
< zoq>
table 1?
< nilay>
yes they have written there the number of filters only right?
< mentekid>
Hey, I have some trouble with Cmake on the AppVeyor build: I use find_package(OpenMP 3.0.0) to detect OpenMP. The package should _not_ be found by the AppVeyor build, since VisualStudio only supports OpenMP2.0... But it finds it (erroneously) and attempts to build it, and the build crashes. Any ideas how I can correctly detect the OpenMP version? Has anyone run into similar problems?
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#1192 (master - 34cf8d9 : Marcus Edel): The build is still failing.
< zoq>
I think what you could do here is to modify the FindOpenMP.cmake file and adjust the test, or you could check the compiler first and skip the (OPENMP_FOUND) section if msvc.
< mentekid>
huh
< mentekid>
I see
< mentekid>
I'll try to do the first one. Thanks!
< zoq>
is this the only problem: 'i': index variable in OpenMP 'for' statement must have signed integral type
< mentekid>
yeah seems like it
< mentekid>
so I could try building a for loop with a size_t
< mentekid>
and if that fails, then the test will fail
< zoq>
you can't just use int instead of size_t?
< mentekid>
where do I look for the FindOpenMP.cmake? It's not in mlpack/CMake
< mentekid>
or should I download it from github and use that?
< zoq>
It comes, with cmake. What I don't like is that in most cases OpenMP 2.0 is just fine.
< zoq>
you could use the version from github
< zoq>
I'm not sure, if you really need size_t
< mentekid>
It isn't really needed - we can do with long long, it just produces warnings because armadillo.n_cols() returns size_t
< zoq>
so, we could cast n_cols once and use that in the for loop?
< mentekid>
I guess... it's not like it will overflow easily
< mentekid>
long long is what? 64 bits at least?
< mentekid>
or 128?
< mentekid>
if somebody has that many points, OpenMP can't help him anyway :P
< zoq>
or we could do the same as in dt_utils.cpp line 183
< zoq>
and yes, long long is at least 64 bits
< mentekid>
I like the dt_utils solution actually
< mentekid>
so since we've solved this problem before there's no reason to reinvent a solution
< mentekid>
cool! thanks :)
< zoq>
yes, I like the idea
< zoq>
tham: The exact policy produces an economy-size decomposition if rows << cols, so maybe you should use cols = rows or rows > cols, to make a comparison.
< rcurtin>
mentekid: zoq: I agree, the dt_utils.cpp solution is good, I forgot about that one
< rcurtin>
zoq: I guess you are right, maybe there is not much compelling reason to force OpenMP 3 if it is only for unsigned index types
< rcurtin>
I think the whole situation is kinda frustrating, but maybe it is better to just work around it instead of throwing Windows users under the bus
< mentekid>
rcurtin: In the end I think the dt_utils.cpp solution ends up being the simplest one, so yeah we can avoid pissing off windows users for no reason
< mentekid>
I'm waiting for appveyor to complete the build but I haven't seen any errors so far so I'm confident
< rcurtin>
ok; once that is done I'll go ahead and merge
< rcurtin>
thanks for the fixes
< rcurtin>
I guess you are moving on to LSH tuning now?
< mentekid>
yeah I started reading the paper on wednesday
< rcurtin>
ok, great
< mentekid>
it's safe to say I understand 5% of it :P
< mentekid>
Once I have a better idea of what I don't understand I'll mail you my questions
< rcurtin>
sounds good; it may take a bit for me to respond since I am not familiar with the exact details of the paper but I will look through the paper on the way home today
Mathnerd314 has joined #mlpack
nilay has quit [Ping timeout: 250 seconds]
mentekid has quit [Ping timeout: 246 seconds]
nilay has joined #mlpack
mentekid has joined #mlpack
mentekid has quit [Ping timeout: 246 seconds]
< zoq>
marcosirc: flann benchmark finished, mlpack results merged, running the ann benchmark now
< zoq>
I can write another benchmark script for e.g. HLearn, if anyone thinks that's a good idea.
< rcurtin>
Mike Izbicki would be happy if you did that :)
< rcurtin>
I think it would be cool to add HLearn, it's apparently quite fast
< rcurtin>
but last time I talked to Mike, he said that he had to do a lot of weird things in Haskell to make it fast. I don't know the details though because I don't know Haskell
< zoq>
so, I guess in this case, can you install HLearn on shoeshine? ... I really like Haskell and the source looks great
< rcurtin>
yeah, sure, let me do that
< rcurtin>
do you want me to update the whole system? (apt-get upgrade, probably dist-upgrade too)
< zoq>
sounds, like a good idea
< rcurtin>
ah but shoeshine is running the benchmarks right now, maybe we should wait?
< rcurtin>
I can still install haskell, that will probably not affect much, but upgrading the whole system might be risky
< rcurtin>
HLearn isn't packaged in the debian repos, so I guess just installing ghc is good enough? let me know if more is needed