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/
nilay has joined #mlpack
< nilay>
when i try to push the blog post it shows the following error: remote: Permission to mlpack/blog.git denied to nilayjain. fatal: unable to access 'https://github.com/mlpack/blog.git/': The requested URL returned error: 403
nilay has quit [Quit: Page closed]
nilay has joined #mlpack
mentekid has joined #mlpack
Mathnerd314 has quit [Ping timeout: 252 seconds]
Mathnerd314 has joined #mlpack
mentekid has quit [Ping timeout: 264 seconds]
Mathnerd314 has quit [Ping timeout: 252 seconds]
mentekid has joined #mlpack
< zoq>
nilay: You need write access to the repository.
< zoq>
nilay: "One last thing, if you like to use the mlpack blog please send us your GitHub
< zoq>
username, so we can give you access to the repository."
< nilay>
zoq: username is: nilayjain
< nilay>
zoq: so i wanted to ask about the view_as_windows function...
< zoq>
nilay: okay, go ahead
< nilay>
it does not preserve the size of the data. . . size becomes larger.. so what happens to the missing entries...?
< nilay>
zoq: do you get my question
< nilay>
by size i mean volume, that is, the total number of entries, in a matrix or a cube...
< zoq>
nilay: the size of ss_ftr?
< nilay>
the shape may change, but how come size. . . and what can we do to implement such a thing. . .
< nilay>
yes
< nilay>
or reg_ftr for that matter
< zoq>
nilay: let me take a look
< nilay>
zoq: ok
< zoq>
nilay: hm, ideally we can avoid the reshaping and resizing operation to increase the performance. I'm not quite sure yet, what's the best way to do this. Since we have to support different image sizes, it's not that easy. I have to think about it.
< zoq>
nilay: So what they did is to go from the original source to a reshaped source and then remove the border. For now, you can just hard code, the last matrix size (1000, 256, 13)
< nilay>
zoq: the last matrix size also does not preserve the volume
< nilay>
zoq: it is not just reshape, there is something else also, so how can we hard code?
< zoq>
nilay: So, you have to create a new matrix or overwrite the existing for ss_ftr = ss_ftr[:, grid_pos] because it chooses n_cell blocks from all samples.
< zoq>
nilay: the same thing for pdist
< nilay>
zoq: what about ss_ftr = view_as_windows(channels, (p_size, p_size, n_ch))
< zoq>
That's just a neat way, to create a 4 tensor matrix. If you go with (1000, 256, 13) for the if else case, we don't have to to that using the channels input.
< nilay>
zoq: ok, but in that step we have changed the shape and size of ss_ftr, and so now how reshaping it to (1000, 256, 13) would be correct?
< nilay>
zoq: do you see the problem, or am i wrong?
< zoq>
nilay: That's what I'll have to think about, do you think it works if you just use (1000, 256, 13) for now?
< nilay>
zoq: so say i use (1000, 256, 13) , but for the entries that are extra, what would be their value
< zoq>
nilay: ah, right
< nilay>
maybe view_as_windows adds some values too?
marcosirc has joined #mlpack
< zoq>
nilay: what this function does is to create all 16x16 patches from input
< zoq>
nilay: we could implement our own view_as_windows function, but I think there is a better way
< nilay>
zoq: ok, go ahead
< zoq>
nilay: hm, we need all patches, so maybe not ...
< zoq>
nilay: Looks like we have to replicate the function ...
< nilay>
zoq: extra dimensions come because when we convert say 5*5 matrix to views of 2*2 matrix, we require 9 matrices. this is because at border we don't have 2*2 patch but we still waste 2*2 matrix for it
< zoq>
nilay: right
< zoq>
nilay: the implementation is straightforward two for loops and extract the submat/subcube at that postion
< nilay>
zoq: anything written in numpy or scipy is difficult to replicate. they just check edge cases with python and call a c function which uses pointers and stuff
< zoq>
nilay: if you like I can write a basic view_as_windows function
< nilay>
zoq: you can tell me and i can try to write it.
< nilay>
zoq: in armadillo we will have to store such views as fields which would be very bad.
< zoq>
nilay: we can just use mat or cube, what's the type of channels in your implementation?
< zoq>
nilay: that function should create a 16x16 patch at (0, 0) (0, 1), (0, 2) ...
< zoq>
nilay: the problem is it's memory inefficient (github page "On my machine, about 12 GB memory is required for training.")
< nilay>
zoq: yes
< zoq>
nilay: I need to think about the problem, maybe we can come up with a better solution ...
< zoq>
nilay: you can also fill the array with dummy values, and use that for testing, maybe I can came back to you tonight with a better solution for the window view problem
< nilay>
zoq: ok
nilay has quit [Quit: Page closed]
mentekid has quit [Ping timeout: 260 seconds]
mentekid has joined #mlpack
Mathnerd314 has joined #mlpack
< zoq>
nilay: So, I think I found a solution, that works, it should consume about 26.6MB ((1000 * 13 * 256) * 8 byte). If you tell me, how the location structure (smp_lock) looks like, I can write that down.
< zoq>
nilay: The great thing is we don't need all patches, we just the the patches at the specified locations which are 1000 as proposed by the authors.
< zoq>
nilay: So you can either use a mat or cube object e.g. a = mat(256, 13 * 1000) or b=cube(16, 16, 13 * 1000) and sample the correct location, so every 13 cols or slices starts a new patch.
< marcosirc>
Thanks. I would like to ask you about the benchmarking system
< marcosirc>
Can I modify it to mesure the number of BaseCases in knn and kfn?
< zoq>
marcosirc: You like to perform some kind of grid search right?
< marcosirc>
No, just to test two different implementations with many datasets.
< nilay>
zoq: Oh sorry, I didn't see logs..
< nilay>
let me check
< zoq>
marcosirc: ah, okay, in this case I guess, you can just add a new config block to the existing config.
< marcosirc>
Ah ok. I should get the number of base cases from the verbose output. Should I add a new metric or something like that?
< nilay>
zoq: so i implemented smp_loc as a cube with 2 slices.
< zoq>
marcosirc: What do you like to measure? time?
< zoq>
nilay: so (#xloc, #yloc, 2)?
< nilay>
zoq: i use find() to calculate the pos_loc and neg_loc locations which are column vectors.
< nilay>
zoq: i can input them any way you want
< marcosirc>
zoq: Not the time. I need to measure the number of times a method "BaseCase" is called. This information is printed in the verbose output of knn and knn.
< nilay>
zoq: smp_loc is only used in reg_ftr and ss_ftr which is where i am stuck at
< nilay>
zoq: i can input pos_loc and neg_loc in any way you want. .. right now we have them as column vectors.
< marcosirc>
Of course I can do it through a bash script. But, I was wondering if I could use the benchmarking system for this...
< zoq>
marcosirc: So I think implementing another metric is the right way, it's straightforward, if you send me the output, I can do that for you, or you can do it yourself. Btw. I can setup a machine with the running benchmark suite you could use, if you like.
< nilay>
zoq: we can use ind2sub to know the subscripts for them.. and yeah.. so that is the smp_loc structure for now.. i don't know if we need a structure for that.
< nilay>
zoq: (uvec& pos_loc, uvec& neg_loc)
< zoq>
nilay: okay, the locations are the same locations as in prepare_data it's pos_loc and neg_loc combined. So if I can choose the representation I would use locations = arma::mat(2, numberlocations).
< zoq>
nilay: So, I could call locations.col(0) to get the firstio x,y location or location(0, 0) to get the first x location.
< marcosirc>
zoq: Thanks. Ok, I will work in the benchmarking repo to add that metric, and I make a pull request when it is ready.
< zoq>
marcosirc: Sounds good, let me know if you need help.
< marcosirc>
Ok. Thanks!
< zoq>
nilay: If you agree, I'll go and use that location structure representation, for the window_view block.
< nilay>
zoq: please give me a minute.
< nilay>
zoq: i didn't understand what you mean by "I could call locations.col(0) to get the first x,y location or location(0, 0) to get the first x location." what i am saying is the following: you have some x number of pos_loc's, and some x number of neg_loc's. (as python codes use rand.permutation to take only x number of locations.). so this is what you have.
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#849 (master - 3d1ed0f : Marcus Edel): The build is still failing.
< nilay>
so an entry in the arma::mat you made is one location.
< nilay>
we can convert that entry (which is an index) to subscript using ind2sub, so that it represents one location.
< nilay>
zoq: are we saying the same thing?
< zoq>
nilay: yes, right, so we end up with an x,y or row,col for one location right?
< zoq>
nilay: ind (e.g 0) -> (0, 0)
< nilay>
yes location[x][y] gives you one location. we concatenate the 2 uvec's to get a size(x,2) matrix. in the first column you have pos_loc and in the second col you have neg_loc
< nilay>
zoq: correct
< zoq>
nilay: okay, so we could store all locations in arma::mat(2, numberoflocations) right?
< nilay>
yes. but i don't know why you use it as (2,numberoflocations), shouldn't it be (numberoflocations, 2)?
< zoq>
nilay: ah, I see, yeah, I think we could use (numberoflocations, 2) or (2, numberoflocations), we just have to use .row or .col
< zoq>
nilay: right
< zoq>
nilay: if you like to go with (numberoflocations, 2), it's fine with me
< nilay>
zoq: i was asking is there any benefit to use (2, numberoflocations)
< nilay>
zoq: so we are taking random features at random locations?
< zoq>
nilay: we use the column-major order, so we should make use of that
< zoq>
nilay: yes, right
< zoq>
nilay: I messed that up in my example, so you are right
< nilay>
zoq: ok i forgot it reverses in column major order, sorry
< zoq>
nilay: so, we agree, to use arma::mat to store the locations right?
< nilay>
zoq: yes
< zoq>
nilay: okay, great, I'll go and write the window_view block, hopefully in the next hours
< nilay>
zoq: if you can please explain your solution again?
< nilay>
then maybe you don't need to write it.. :)
sumedhghaisas has joined #mlpack
< sumedhghaisas>
marcosirc: hey marcos...
< marcosirc>
Hi sumedh.
< sumedhghaisas>
rcurtin: Lets just also ping Ryan... he might give some inputs too...
< sumedhghaisas>
okay so... I read your last comment on github...
< sumedhghaisas>
I agree about changing the code to test your function...
< sumedhghaisas>
That would mean pushing our timeline a bit...
< marcosirc>
Yes.. I have been working today in the implementation of b_aux. It was simple to fix.
< marcosirc>
I have tested it in the corel dataset, resulting in exactly the same number of base cases after the modification than with the original b_2 bound.
< marcosirc>
Even for cover trees.
< marcosirc>
I was thinking of using the benchmarking system to test this with many different datasets. Once we check everything is ok, the code could be merged.
< marcosirc>
Would you agree on this? I will try to finish this as fast as I can so we can continue with the proposed timeline.
< sumedhghaisas>
hmm... thats good... but I think for trees on which B2 is correct... b2 is definitely tighter...
< sumedhghaisas>
So its worth adding another another trait... what do you think??
< marcosirc>
Well... Yes. Because of that, I proposed to include some information in the treetraits to decide if we want to use previous b2 bound.
< marcosirc>
Yes!
< sumedhghaisas>
Sure no problem... If you have already pushed the code I am happy to take a look at it...
< marcosirc>
I would have expected to notice a difference in the number of base cases with cover trees (between original b2, and b_aux modification). But I haven't. I will test with other dataset to see what happens.
< sumedhghaisas>
thats right... lets see what Ryan has to say about the train addition.
< marcosirc>
(because cover trees would be the only interesting case where it makes sense to have a difference, because it holds points in non-leaf nodes).
< sumedhghaisas>
yes thats true...
< marcosirc>
I will push the code now.
< sumedhghaisas>
even I expected that... maybe we can generate a small dataset which will force the difference??
< sumedhghaisas>
might be a good test case in our Boost system...
< sumedhghaisas>
We can set some Ci's like you did in your example... then generate some points statistically around it...
< marcosirc>
Well.. Yes, a dataset to force the difference in cover trees would be interesting. I don't have a deepth understanding in how cover trees work, I would need some time to go in depth about them ...
< marcosirc>
Do you mean the example I mentioned where b2 fails?
< sumedhghaisas>
yes... I think you followed a similar approach in producing the tree...
< sumedhghaisas>
The tree where B2 fails will be good starting point to generate a difference...
< marcosirc>
Mmm, If we want to have a difference in the number of base cases for cover trees, I think we should think in a different example.
< marcosirc>
The example I mentioned was a tree using hyperrectangle bounds.
< marcosirc>
And was an example where b2, fails.
< marcosirc>
Cover trees use ball bounds. And we do not need an example where b2 fails. In fact b2 doesnt fail. We need an example where b2 mean more prunning than b_aux...
< sumedhghaisas>
ohh no... when I said a test case for Boost I mean to write a test where B2 will fail and B aux won't...
< sumedhghaisas>
Not for cover trees...
< sumedhghaisas>
that another scenario...
< sumedhghaisas>
sorry for the confusion...
< marcosirc>
Ahhh... that makes sense.
< marcosirc>
Ok.
< sumedhghaisas>
yes for ball bound finding an differencing forcing example would be difficult...
< sumedhghaisas>
we would need to play upon the difference between B2 and Baur ...
< marcosirc>
Well. With actual tree types, that interesting case can not be implemented, because all trees using hyperrectangles, such as KDTree/R-Tree/R*-Tree/X-Tree, only hold point in leaf nodes.
< sumedhghaisas>
yeah ... where we know B2 might fail ...
< marcosirc>
Yes, if we want to force b2 to fail, we need to hold points in a non-leaf node...
< marcosirc>
Maybe some of the new tree types, that Mikhail Lozhnikov is implementing for this GSoC...
< sumedhghaisas>
not even ball tree I assume ... not very familiar with that but its just hypersphere partitioning I think...
< marcosirc>
Yes... Ball trees only hold point in leaf nodes as KDTrees..
< sumedhghaisas>
yeah just read about them...
< sumedhghaisas>
okay so what I am wondering is... Why not think about the framework changes when the appropriate tree is implemented??
< sumedhghaisas>
What I mean is... without the tree with hyper rectangular bounds with leaf node carrying points...
< sumedhghaisas>
Won't it be hand to test Baux??
< marcosirc>
So, I am not sure if I understand. Do you mean waiting until we have a tree type that fails?
< sumedhghaisas>
yeah... I am not sure if its the right way... but I am thinking about it...When we actually have that tree we would have better understanding of exactly what framework changes are needed...
< sumedhghaisas>
to use both baux and B2
< sumedhghaisas>
and the change will be smoother at that point I think...
< marcosirc>
Well... that is an option. You will have to remember to update the code when adding new tree types...
< marcosirc>
I thought it would be useful to be sure we have the correct bounds before continuing.
tsathoggua has joined #mlpack
tsathoggua has quit [Client Quit]
< marcosirc>
I don't think b_aux involves many changes, with the advantage that we know it is correct. But if you prefer, we can wait..
< sumedhghaisas>
yeah thats the negative side of it :( anyways since you have already started making changes...
< sumedhghaisas>
yeah... thats what I was saying :)\
< sumedhghaisas>
lets think about merging later... we will also discuss with ryan ...
< sumedhghaisas>
I will first take a look at the code...
< sumedhghaisas>
we know its correct so lets proceed with it...
< marcosirc>
Thanks. Ok. So, if you agree, I can do more tests with different datasets while we wait for Ryan's opinion.
< sumedhghaisas>
Surely...
< sumedhghaisas>
it would be interesting to see the test data where there is a difference in base cases...
< sumedhghaisas>
if you find one in your datasets...
< marcosirc>
I agree.
< marcosirc>
If we don't see any difference in popular datasets, we would have to think about a special case... I need to read more about cover trees.
nilay has quit [Quit: Page closed]
sumedhghaisas has quit [Ping timeout: 244 seconds]
< rcurtin>
marcosirc: sumedhghaisas: just read the conversation
< rcurtin>
I think the RectangleTrees hold points not just in the leaves but also in higher level nodes
< rcurtin>
so maybe it is possible to synthesize a problem case that shows b_2 fails
< rcurtin>
but it would probably be very difficult
< rcurtin>
when I synthesized a test dataset to demonstrate an error with John Langford's cover tree code it took I think a full week
< rcurtin>
I think switching to b_aux is fine, but I need to read the existing ticket and add a comment
< marcosirc>
rcurtin: Thanks for your comments! When you say rectangle tree, do you mean R-tree? I have been reading the code, and it doesn't seem to save point in non-leaf nodes.
< marcosirc>
I have to read it in detail, but that was my impression after reading the RTreeSplit's code.
mentekid has quit [Ping timeout: 258 seconds]
marcosirc has quit [Quit: WeeChat 1.4]
< rcurtin>
marcosirc: sorry for the slow response, I am in the car, long drive home...
travis-ci has joined #mlpack
< travis-ci>
mlpack/mlpack#850 (master - 2fe9e82 : Ryan Curtin): The build was fixed.