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/
< Rei[m]> #techprog:matrix.org
Rei[m] has left #mlpack []
ImQ009 has joined #mlpack
< rcurtin[m]1> Hey Rishabh Garg (Gitter), if you're going to use `std::move()`, no need for a reference on the left hand side (e.g. use `arma::mat dataset` not `arma::mat& dataset`) 👍
< RishabhGargGitte> Thanks a lot @rcurtin . It resolved the errors ^_^
< rcurtin[m]1> awesome 👍ī¸
kkothari2001 has joined #mlpack
kkothari2001 has quit [Client Quit]
< shrit[m]> @rcurtin, Do I need to print all the members of the cover tree class?
< rcurtin[m]1> where are you referring to?
< shrit[m]> DualCoverTreeMapEntry
< shrit[m]> it has a reference node inside which is a CoverTree
< rcurtin[m]1> oh, for that I would just print the first point and number of descendants
< rcurtin[m]1> we can use that as our "unique" cover tree node identifier
< shrit[m]> ok you mean node.Point(0)
< rcurtin[m]1> right
< jonpsy[m]> Hey zoq would you mind reviewing my nsga2 PR anytime soon? I want to do the parallelizing on another PR to preserve scope.
< jonpsy[m]> BTW ive started working on that old MOEA/D-DE PR. I'll be pushing that soon, would love your reviews there. Good day!
< zoq> jonpsy[m]: Sure, I'll take a look.
< shrit[m]> rcurtin:
< shrit[m]> Just finished the last tests
< shrit[m]> I am sending you the results now
< rcurtin[m]1> 👍ī¸
< shrit[m]> I wish if I had a better understand of these tree, frankly, it is very hard to understand what is happening
< shrit[m]> Also, it is your thesis subject,
< rcurtin[m]1> they are quite complicated, unfortunately, especially the cover tree
< rcurtin[m]1> am I reading it right that at that moment there is only one reference node in `referenceMap`?
< rcurtin[m]1> I think that will work... you might need to debug it a little, I may have made a small mistake while writing it
< rcurtin[m]1> but I am wondering if somehow these two reference trees do not have the same structure or something
< shrit[m]> I will send you the two source code, it is harder to tell than to have a look
< rcurtin[m]1> in essence the same debugging process I am guiding here you actually could do without too much knowledge of the tree itself---basically we just need to find the first place in `FastMKS::Search()` where the output is different
< rcurtin[m]1> so far we know that somewhere after we start the dual-tree recursion, things are different, so we just need to track down why those things are different
< rcurtin[m]1> I would have figured that the output from the tree-building process would be sufficient to say the reference trees were the same on each device, but I am not 100% sure now given the output you sent... so it probably makes sense to double-check
< shrit[m]> Actually I ran both tests at the same device(viking)
< shrit[m]> I have only generated one dataset, so it should be the same
< rcurtin[m]1> do you mean the test fails when statically linked on viking also?
< shrit[m]> yes
< rcurtin[m]1> does it fail when statically compiled on an x86-64 system?
< rcurtin[m]1> (as in, not cross-compiled)
< shrit[m]> I have no idea
< rcurtin[m]1> probably worth checking---it could save you a lot of time when iterating and debugging if you don't have to cross-compile :)
< rcurtin[m]1> also, I think you should print the contents of `referenceMap` immediately at the beginning of `DualTreeTraverser::Traverse()`; the code right now only prints sometimes, if we get to a base case
< shrit[m]> OK, I will build it statically on the same machine, that will save a lot of time,
< rcurtin[m]1> yes, and if you can reproduce on any arm64 system or any x86-64 system, I can probably just take over the debugging since I have both of those here
< rcurtin[m]1> I don't have an RPi set up though
< rcurtin[m]1> maybe can you open a github issue with build instructions so that I can try and reproduce the whole thing locally?
< shrit[m]> Until now, I was able to reproduce the issue on any arm64, but I have no idea for x86_64
< rcurtin[m]1> when you reproduce the issue, are you cross-compiling to arm64 from an x86-64 host? or compiling directly on arm64?
< rcurtin[m]1> I'm just trying to figure out how many variables we have here... e.g., whether or not it's a function of static linking, cross-compilation, or both
< shrit[m]> The tests pass when compiling locally on arm64, but fails when cross compiled from x86_64 to arm64
< rcurtin[m]1> I see, so cross-compilation is necessary
< shrit[m]> that said,I never tried to statically link a locally compiled one on arm64
< rcurtin[m]1> ahh, do you think you can try that?
< rcurtin[m]1> that will be really helpful to narrow down how this can be reproduced
< shrit[m]> Yeah, this will tell us if the problem is from the cross compilation or from the statically linking
< rcurtin[m]1> 👍ī¸
< shrit[m]> I will let know in an hour
< shrit[m]> Ooops, I discovered a small bug,
< shrit[m]> but it did not change the results,
< shrit[m]> Apparently, I was always compiling `mlpack_test` dynamically,
< shrit[m]> thinking that it was linking statically, because all mlpack binaries are linking statically
< shrit[m]> this one is linking statically for all binding, since I wrote that last year, I completely forgot about `mlpack_test` thinking that it is produced with the same Cmake config.
< shrit[m]> I statically linked mlpack_test now, but it still failing
< shrit[m]> Sorry ☚ī¸
< shrit[m]> Anyway, I will create a statically linked config for mlpack_test on x86_64 let us see if this fails
< rcurtin[m]1> ok, no worries, you are saying the failure is still there but only when statically linking?
< shrit[m]> no, it was failing when I was dynamically linking and cross compiling
< rcurtin[m]1> but it succeeds when statically linking?
< shrit[m]> nope
< rcurtin[m]1> interesting; so the last part of that 2x2 matrix is 'locally-compiled static linked arm64', very interested to see what that result is :)
< shrit[m]> yeah, compiling a compiler now
< rcurtin[m]1> 👍ī¸
< shrit[m]> the missing part is gfortran in static format in both x86_64 and arm64, otherwise everything is here
ImQ009 has quit [Quit: Leaving]
< shrit[m]> Interesting to see how much gcc takes time to compile and consume a few amounts of memory
< shrit[m]> I will complete the matrix tomorrow, gcc takes a lot of time to compile
< rcurtin[m]1> it sure does 😃