14:32 < rcurtin> so I keep a script on mlpack.org that prints the number of downloads of each version of the library, and I definitely notice an uptick in recent months

14:32 < rcurtin> let's see if I can copy-paste the numbers successfully...

14:33 < rcurtin> $ mlpack-downloads

14:34 < rcurtin> 1785 mlpack 1.0.0

14:34 < rcurtin> 2043 mlpack 1.0.1

14:34 < rcurtin> 3824 mlpack 1.0.10

14:34 < rcurtin> 3620 mlpack 1.0.11

14:34 < rcurtin> 7559 mlpack 1.0.12

14:34 < rcurtin> 1342 mlpack 1.0.2

14:34 < rcurtin> 2069 mlpack 1.0.3

14:34 < rcurtin> 4351 mlpack 1.0.4

14:34 < rcurtin> 1662 mlpack 1.0.5

14:34 < rcurtin> 2814 mlpack 1.0.6

14:34 < rcurtin> 2786 mlpack 1.0.7

14:35 < rcurtin> 6762 mlpack 1.0.8

14:35 < rcurtin> 3715 mlpack 1.0.9

14:35 < rcurtin> 2189 mlpack 2.0.0

14:35 < rcurtin> 3715 mlpack 2.0.1

14:35 < rcurtin> 1551 mlpack 2.0.2

14:35 < rcurtin> 2432 mlpack 2.0.3

14:35 < rcurtin> 5148 mlpack 2.1.0

14:35 < rcurtin> 2375 mlpack 2.1.1

14:35 < rcurtin> 2184 mlpack 2.2.0

14:35 < rcurtin> 886 mlpack 2.2.1

14:36 < rcurtin> 1428 mlpack 2.2.2

14:36 < rcurtin> 1156 mlpack 2.2.3

14:36 < rcurtin> 2385 mlpack 2.2.4

14:36 < rcurtin> 3766 mlpack 2.2.5

14:36 < rcurtin> 949 mlpack 3.0.0

14:36 < rcurtin> 686 mlpack 3.0.1

14:36 < rcurtin> 809 mlpack 3.0.2

14:36 < rcurtin> 903 mlpack 3.0.3

14:37 < rcurtin> so now, the rates are like 1k downloads/month with the 3.x versions, but 2.2.5 was collecting downloads at more like 500-600/month

14:37 < rcurtin> this also doesn't count anyone who downloaded directly from github or from a package manager

14:37 < rcurtin> still, it's cool to see the downloads going up :)

14:42 < zoq> would be interesting to correlate the numbers with the time between releases

14:51 < zoq> wondering if you could see certain events in the data like a paper, maillinglist announcement or GSoC

14:51 < zoq> I guess you can just speculate what a peak might corelate with.

15:15 < rcurtin> right, I remember doing this once and there were typically spikes just after releases

15:16 < rcurtin> http://mlpack.org/mlpack-downloads.png

15:23 < zoq> you can definitely see a trend

15:58 < Shikhar> rcurtin: Is a new release in the works for the near future? I had read someone mention in the IRC a while back that a new release is likely after GSoC?

15:59 < rcurtin> yeah, it would be a good idea, we could put one together shortly

15:59 < rcurtin> the only question is what to include and which PRs to wait on :)

16:00 < Shikhar> rcurtin: As for the ANN module, I don't think there is anything that needs to be put on hold. Any major update is currently WIP, and can be incorporated later.

16:05 < rcurtin> sounds good---let's see if I can find some time tomorrow or in the next couple days to start organizing a release; this one will be 3.1.0 since we have added a lot of support from GSoC projects

16:13 < Shikhar> zoq: Are you there?

16:20 < Shikhar> zoq: I was thinking of implementing cyclegan, as a separate class in mlpack. The reason why I'm suggesting this is because it deviates from the standard one generator, one discriminator architecture that we usually associate GANs with. We would require two discriminator for CycleGAN, and that would be a deviation form the API that we have developed for the generic GANs like GAN, DCGAN, WGAN and WGAN-GP.

16:25 < Shikhar> zoq: For other generic GANs, we can simply introduce policies, like we do currently, and with minimal changes we can get them merged. But with outliers like StackGAN, CycleGAN and other niche GANs, I think it will be a better thing to have separate class, since their structure isn't really generalizable.

16:48 < Shikhar> zoq: I've pushed the skeleton structure to CycleGAN class, which follows from the GAN class. Please take a look and let me know what you feel.

16:50 < zoq> Shikhar: Agreed, it's probably cleaner to implement this one as an independent module.

16:51 < zoq> Shikhar: Will take a look at the code later today.

16:52 < Shikhar> zoq: Cool, I'm yet to implement the low level functionality, but that should be done over the weekend. Gonna dive into the paper for now.

16:54 < zoq> Shikhar: It's not to far-off from the models you already implemented.

16:56 < Shikhar> zoq: Yeah, but the structure would be different, as it takes 2 discriminators, and the loss functions are also modified. One thing I really like about the paper is that the cyclic loss function is so intuitive! Makes me think that if not for Jun-Yan Zhu, someone else would have easily arrived at it independently!

17:01 < zoq> Shikhar: maybe not