cameron.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/
jbc_ has joined #mlpack
jbc_ has quit [Quit: jbc_]
jbc_ has joined #mlpack
jbc_ has quit [Quit: jbc_]
jaskaran has joined #mlpack
jaskaran has quit [Client Quit]
jbc_ has joined #mlpack
ashishtilokani has joined #mlpack
< ashishtilokani> Hi Ryan! Yesterday I went through some source files and tutorials.
< ashishtilokani> Now I am looking at the tickets.
< ashishtilokani> I might be wrong but #209 does not seem very difficult to solve. Should I spend some time on it or is there any other not so difficult bug I should try first.
< naywhayare> ashishtilokani: a first place to start would be detecting when there is not enough available memory to transpose a matrix
< naywhayare> and then if that condition is true, doing in-place transposition
< naywhayare> but I would also want to see how much slower in-place transposition is
< naywhayare> when we have those figures, we can make a decision on what the best approach is
ashishtilokani has quit [Ping timeout: 246 seconds]
< zoq> ashishtilok: Maybe you already know this, but armadillo provides an in place method to transpose a matrix.
< naywhayare> zoq: huh, I didn't know that
< naywhayare> that makes the ticket even easier then, I guess :)
< naywhayare> I think one just has to catch when the malloc fails, then do the inplace transposition
ashishtilokani has joined #mlpack
< zoq> I'm not sure if this will solve the problem: http://scvalex.net/posts/6/
< ashishtilokani> So should I first study more about the running time of in place transposition or implement it and run it on large sample matrices to see the running time?
< naywhayare> ashishtilokani: zoq pointed out right after you left that armadillo actually has in-place transposition
< naywhayare> I don't think it did when the ticket was filed...
< naywhayare> anyway, I think all you need to do is figure out when there's not enough memory, then call the in-place transposition function instead
< naywhayare> I am still curious to see how much slower it is than non-inplace transposition
< ashishtilokani> ok
< zoq> naywhayare: yeah, me too
< ashishtilokani> I guess the way to address the first problem is to try out matrices of progressively larger sizes and see when it fails
< ashishtilokani> If this is the approach I can try it out
< ashishtilokani> and using mlpack timers I can easily compare the time taken by the two apporaches
< zoq> You can definitely compare the two approaches with different sizes using the mlpack timer class. This will provide some insights on how the different approaches are performing.
< zoq> But I'm not sure if there is a good method to choose the right transposing method (e.g. checking if malloc fails).
< ashishtilokani> I guess just based on the number of dimension of matrix choosing the transposition method wont be useful
ashishtilokani has quit [Quit: Page closed]
< zoq> The number for one system isn't necessary the best value for another system. Even on the same system the number isn't always the best you can choose, depending on side effects like other processes that need more memory.