[mlpack-git] [mlpack/mlpack] LSH optimization: LSHSearch::ReturnIndicesFromTable uses less memory (#623)

[Yannis Mentekidis]

My concern is that the candidate size counting would take more time in
multiprobe. On the other hand that should not be a big factor in total time.

At some point I was confused and thought multiprobe would also return
larger candidate sets, but that's not true - if run correctly it should
return smaller sets since there's more hash buckets but fewer tables. So I
think unique would actually be the way to go here.

I think you should go ahead and merge it, and I'll make the corresponding
changes in the multiprobe code. As we discussed the hybrid option might not
be so good - if I remember well we did shave off a bit of time but the code
will become too complex once multiprobe is added.

On Sun, Jun 5, 2016 at 9:34 PM, Ryan Curtin <notifications at github.com>
wrote:

> What did you want to do with this PR? I am happy to merge it in now, but I
> remember that you said you thought it would be less effective for
> multiprobe LSH. (Maybe the thing to do for multiprobe LSH is just to factor
> in however many extra tables are being checked into the calculation?)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/mlpack/mlpack/pull/623#issuecomment-223829195>, or mute
> the thread
> <https://github.com/notifications/unsubscribe/AFxX3Nw55hdLVdG4NB9rmPyWP_CRaSNbks5qIxawgaJpZM4II_F4>
> .
>


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mlpack/mlpack/pull/623#issuecomment-223830325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.cc.gatech.edu/pipermail/mlpack-git/attachments/20160605/2c57ff40/attachment.html>