11:51 < RishabhGarg108Ri> @ryan:ratml.org I am extremely happy. I managed to get 0.0 MSE on the UCI energy dataset. 😃

11:52 < RishabhGarg108Ri> Actually the gain computation was wrong. In the buggy implementation, the gain was calculated as `Sum of squared residuals` / `Number of elements in leaf`

11:53 < RishabhGarg108Ri> But, the normalization in the denominator was causing the whole issue.

11:54 < RishabhGarg108Ri> In the next few hours, I will do a little more testing to be really sure that it was the issue. I will update you once I am 100% sure

12:19 < jonpsy[m]> RishabhGarg108 (RishabhGarg108): Grats!

12:20 < jonpsy[m]> coincidentally enough, very recently I had success with this extremely messy policy design pattern. It finally compiled :D . Lucky stars, eh?

12:26 < rcurtin[m]1> very nice RishabhGarg108 (RishabhGarg108) and jonpsy !

13:22 < rcurtin[m]1> zoq: as I work on this `ann-vtable` branch, I've been thinking more about these types of architectures like inception and others where layers can split into multiple layers and then rejoin later in the network... our FFN class represents layers as a `std::vector<Layer*>`, but this is actually not sufficient to capture any general DAG-like structure... so I wonder if it makes more sense to have a `DAGNetwork` class (maybe

13:22 < rcurtin[m]1> it needs a better name) for these more complicated structures, and then we can provide a user an interface where they can, e.g., send the output of one layer to multiple other layers, and merge the outputs of many layers into one. internally this `DAGNetwork` class would have to manage a general DAG and do backpropagation through it, but this is a fairly easy problem to solve, and I think a lot easier than the various

13:22 < rcurtin[m]1> techniques we have in place for DAG-like networks in `FFN`. let me know what you think... right now it's just an idea in my head

13:40 < RishabhGarg108Ri> @jonpsy:matrix.org yep. Lucky day :)

13:41 < RishabhGarg108Ri> @ryan:ratml.org I tested for trees of different depths and the splits made by our tree are exactly the same as that of sklearn's implementation.

13:43 < RishabhGarg108Ri> I am still struggling with the loading of the Boston housing dataset. Can you please give a small script that correctly loads it. With this dataset, I will test the categorical split.

13:52 < HarshVardhanKuma> Hey guys. I am stuck at trying to run decision trees cli binding on a armadillo binary .bin file (created by reading a csv file into arma::matrix and then storing it in .bin format). Other methods run fine.

13:52 < HarshVardhanKuma> Is this an issue with the decision tree implementation? Can you confirm this?

13:54 < HarshVardhanKuma> Always gives the following error: [FATAL] Unable to detect type of '../../datasets/10lakh/make_blobs_100_clusters_x.csv.bin'; incorrect extension?

13:54 < HarshVardhanKuma> run on a linux machine, with mlpack installed using sudo apt and run using cli bindings.

13:54 < HarshVardhanKuma> * Always gives the following error: [FATAL] Unable to detect type of '../../datasets/10lakh/make_blobs_100_clusters_x.csv.bin'; incorrect extension?

13:56 < HarshVardhanKuma> * Always gives the following error: [FATAL] Unable to detect type of '../../datasets/10lakh/make_blobs_100_clusters_x.bin'; incorrect extension? (The dataset is generated using sklearn make_blobs method, then saved as a csv using numpy and then loaded and saved as a .bin file using armadillo load method)

15:42 < jonpsy[m]> > You can also use docker on the machine, that way you have root as well.

15:42 < jonpsy[m]> So you mean docker inside the remote machine?

15:42 < jonpsy[m]> Ahhhhhhhhh, i finally get it now

16:55 < zoq> rcurtin[m]: Besides the res-block functionailiy which we replaced right now with the AddMerge layer, I think the FFN class does not handle anything like that? I'm totally fine to remove that part from the the FFN class and have something specific, I guess the Merge layers go into that direction.

16:55 < zoq> jonpsy[m]: Yes, just start a docker and inside the docker you can do whatever you want.

17:02 < zoq> HarshVardhanKuma: I guess when you saved the file as binary using armadillo you just used the default option (arma_binary)?

17:03 < zoq> HarshVardhanKuma: Are you able to load that file with armadillo?

17:48 < rcurtin[m]1> RishabhGarg108 (RishabhGarg108) sure, let me try to make a working example later today

17:48 < rcurtin[m]1> zoq yeah, sounds good... I'll work my way through the layers little by little and maybe something like a `DAGNetwork` can remove the need for some of the `AddMerge` layers and similar

18:07 < zoq> rcurtin[m]: Let me know if there is anything I can help with.

19:58 < Aakash-kaushikAa> Hey @zoq and @kartikdutt18 will it be possible for you guys to shift the meeting from monday(14 june) to Sunday(13 june) for the same time? and i have been thinking that instead of monday we can have our meet on saturday if that works for you guys.

20:02 < Aakash-kaushikAa> And maybe i talk about pytroch a bit too much but it really simplfies the process of trying something new by just letting the user define the flow very easily, you can do almost anything with the tensors in between and then pass them to the next layer.

20:03 < rcurtin[m]1> agreed Aakash-kaushik (Aakash kaushik) , what you suggested is what I'm hoping for. I will definitely tag you on any proposal (but it may be a little while before we get there)

20:05 < Aakash-kaushikAa> I totally understand this part, but I am happy we are doing something towards this. because just like other algortihms DL is not systematic on which step should come after one, people try to mix and match things and apply different say computations in between for research.

20:05 < Aakash-kaushikAa> I believe for the ANN side we are a bit stiff on what someone can do with mlpack

20:21 < zoq> Aakash-kaushikAa: I'm trying to not have meetings on the weekend, it's the weekend; so I would prefer it if we can keep it on Monday. If you just want to shift the Monday 14th meeting to Sunday, I could make that work.

20:58 < Aakash-kaushikAa> @zoq totally understand this, we can have our meet on monday.

21:00 < Aakash-kaushikAa> The main reason for proposing this was to make things more efficient because i get a lot more time over the weekend rather than weekdays so a lot of the things i want to discuss build up by say friday or saturday.

23:03 < heisenbuugGopiMT> Started writing my gsoc blog: https://heisenbuug.github.io/

23:04 < heisenbuugGopiMT> It is very basic for now, I will keep working on it...

23:14 < shrit[m]> thanks I will have a look