02:33 < kartikdutt18[m]> Downloading is not really an issue, We already have added a downloader using boost in C++ in the models repo. I think the context is to allow download during runtime. This would be especially useful when a user tries to download weights and datasets, the repo would automatically download only the required weights and datasets.

02:33 < kartikdutt18[m]> We can download using CMake or python script or both for pre-runtime downloads. Run time downloads would make even more sense if we use mlpack-models in notebooks. Also, I think most libraries like PyTorch and Tensorflow support runtime downloads. Kindly let me know what you think. Thanks.

02:38 < kartikdutt18[m]> The problem lies with unzipping files, we can either have seperate files for testing and training on the server or we can add a dependancy to models repo and resolve it locally.

02:46 < rcurtin> ohhh, I see what you mean. probably way better to add the dependency to the models repo then, because compression is really important for keeping bandwidth usage down

02:46 < rcurtin> sorry that I misunderstood the usage :)

03:04 < kartikdutt18[m]> No worries, makes sense. Will open a PR for it. Thanks a lot.

05:48 < learnerml> Hi ... Is mlpack allowed to use for commercial purpose ?

06:03 < learnerml> Like for integrating in some business analytics product ?

06:34 < birm[m]> See the license detail: https://github.com/mlpack/mlpack/blob/master/LICENSE.txt

06:34 < birm[m]> and a summary of bsd 3: https://choosealicense.com/licenses/bsd-3-clause/

06:35 < birm[m]> my messages and the links contained are not legal advice.

06:37 < birm[m]> learnerml: hopefully that is useful info for your purposes

09:23 < jeffin143[m]> Windows got , winget -package manager

09:23 < jeffin143[m]> May be we can simply do winget install mlpack

09:23 < jeffin143[m]> And puff there is mlpack

10:53 < KimSangYeon-DGU[> Can I re-run only AppVeyor build?

11:00 < KimSangYeon-DGU[> And it seems pvs-studio-analyzer and plog-converter aren't able to be found in Static Code Analysis check

11:04 < nishantkr18[m]> Hey everyone. I'm having some confusion in FFN::Backward() function.. I dont get why we provide input as a parameter to it?

11:07 < nishantkr18[m]> I suppose we store the activations we get with the Forward() function, in the network object internally.. In that case, we should just require to pass the target and lvalue of gradient to Backward()

11:07 < nishantkr18[m]> right?

11:11 < zoq> nishantkr18[m]: There is no requirement to store the output activation in the layer itself, so it's safer to use the input.

11:11 < zoq> KimSangYeon-DGU[: We have to install pvs studio on another host, since masterblaster is down.

11:12 < zoq> KimSangYeon-DGU[: Also what build do you like to restart, maybe there is some setting that's not right.

11:14 < KimSangYeon-DGU[> <zoq "KimSangYeon-DGU: Also what build"> Thanks, zoq. I want to re-run the AppVeyor build in https://github.com/mlpack/mlpack/pull/2410

11:15 < kartikdutt18[m]> Hi KimSangYeon-DGU , @zoq, Let me just merge the master with my branch that will trigger the builds again.

11:16 < KimSangYeon-DGU[> kartikdutt18 (@kartikdutt18:matrix.org): Yes, thanks!

11:18 < KimSangYeon-DGU[> Or we simply close and re-open the PR to trigger all the builds

11:18 < KimSangYeon-DGU[> But I wanted to re-run the only failed build :)

11:19 < zoq> KimSangYeon-DGU[: The settings look okay to me, I guess you used the github account to login to appveyor?

11:20 < KimSangYeon-DGU[> <zoq "KimSangYeon-DGU: The settings lo"> Yes

11:20 < KimSangYeon-DGU[> With the same account as GitHub

11:21 < KimSangYeon-DGU[> Ahh,

11:22 < kartikdutt18[m]> Ahh, sorry about that. It will take about an hour now.

11:45 < KimSangYeon-DGU[> Oh, no worries :)

17:22 < himanshu_pathak[> Hey anyone why azure build are not running on my pr https://github.com/mlpack/mlpack/pull/2261

17:22 < himanshu_pathak[> * Hey anyone know why azure build are not running on my pr https://github.com/mlpack/mlpack/pull/2261

17:24 < zoq> himanshu_pathak[: Hm, can merge in the latest master branch?

17:26 < himanshu_pathak[> zoq:ok, I need to do a rebase for this

21:53 < rcurtin> follow-up from the video call discussion about the bindings: https://github.com/mlpack/mlpack/issues/2421

21:56 < jeffin143[m]> Completely missed it

22:00 < shrit[m]> rcurtin I am sorry but I had to miss video chat today

22:00 < shrit[m]> I have some question about lapack

22:03 < shrit[m]> it seems to me that OpenBlas implements basic algebra operation, which is very optimized. While LAPACK on the other hand, implements more complicated algebra operation, LAPACK requires OpenBlas as a dependecy. So LAPACK needs to link against OpenBlas or any blas library.

22:04 < shrit[m]> Armadillo is a wrapper for LAPACK, so Armadillo requires LAPACK and OpenBLAS

22:36 < eddelbuettel[m]> Not quite. OpenBLAS is one of many BLAS libraries. Atlas or MKL are others. Armadillo works with any one of them.

22:38 < eddelbuettel[m]> And doesn't care which as all implement the BLAS /LAPACK api.

22:38 < shrit[m]> Exactly, but Armadillo requires both of them

22:38 < shrit[m]> BLAS and LAPACK,

23:02 < rcurtin> shrit[m]: right, sorry for the slow response (no worries about missing the video meeting)

23:02 < rcurtin> now I had thought---but I could be incorrect---that OpenBLAS also had a LAPACK implementation

23:03 < rcurtin> what I know is that when I use Armadillo without the wrapper, it's generally sufficient to just link with -lopenblas (i.e. -llapack -lopenblas isn't needed)

23:03 < rcurtin> however, I'm not sure of the exact underlying details of why

23:03 < rcurtin> so, perhaps I could be wrong

23:04 < shrit[m]> I am sure of what you said shoud be true

23:04 < rcurtin> I'm not :-D

23:05 < shrit[m]> Because that what OpenBlas website is claiming

23:06 < shrit[m]> I as digging inside the archive of libopenBlas.a (I compiled it with LAPACK support) but still there are some symbols are missing

23:09 < shrit[m]> For example: dgeqrf_, dorgqr_, dsyevd_, dgesdd_ are required by mlpack_knn but still not found in openblas

23:11 < rcurtin> so I went and grabbed the OpenBLAS distributed with Julia:

23:11 < rcurtin> https://github.com/JuliaBinaryWrappers/OpenBLAS_jll.jl/releases

23:11 < rcurtin> that's dynamically linked, but not to any LAPACK library

23:11 < rcurtin> I see this on the inside:

23:12 < rcurtin> $ strings libopenblas64_.so | grep dgesdd_

23:12 < rcurtin> LAPACKE_dgesdd_work

23:12 < rcurtin> lapacke_dgesdd_work.c

23:12 < rcurtin> LAPACKE_dgesdd_work64_

23:12 < rcurtin> dgesdd_64_

23:12 < rcurtin> dgesdd_64_

23:12 < rcurtin> LAPACKE_dgesdd_work64_

23:12 < rcurtin> so, maybe they are inlining LAPACK somehow into the library?

23:14 < shrit[m]> strings libopenblas.a | grep dgesdd

23:14 < shrit[m]> exit 1

23:14 < shrit[m]> hmm interesting

23:14 < rcurtin> strange!

23:16 < shrit[m]> find . -name "*.a"

23:16 < shrit[m]> ./libopenblas.a

23:16 < shrit[m]> ./libopenblas_armv8p-r0.3.9.a

23:16 < shrit[m]> So they are inside these archive, no way

23:17 < rcurtin> tjat

23:17 < rcurtin> *that's from the julia download?

23:17 < rcurtin> I downloaded the x64 version

23:17 < rcurtin> OpenBLAS.v0.3.9.x86_64-linux-gnu-libgfortran5.tar.gz

23:18 < shrit[m]> Actually this is the cross compiled version of the github website I think

23:18 < shrit[m]> aarch64

23:18 < shrit[m]> (I have cross compile it)

23:23 < rcurtin> hmm, maybe the Julia compilation scripts are doing something to combine them? I'm not sure

23:27 < shrit[m]> Do you have a link for the julia download please?

23:27 < rcurtin> just one of the .tar.gzs from https://github.com/JuliaBinaryWrappers/OpenBLAS_jll.jl/releases

23:32 < shrit[m]> Yes julia .so has these symbols

23:32 < shrit[m]> My own .so on my /usr/lib also does not have them

23:34 < rcurtin> hmm, no idea what build magic they are doing to do that though

23:34 < rcurtin> I linked to the build script earlier in your PR, maybe that link is helpful?

23:34 < rcurtin> in any case, I'm sure there are many ways to solve the problem, and maybe it always boils down to compiling LAPACK

23:39 < shrit[m]> I am sure of that, it is simple, I will have to read the MakeFiles of OpenBlas in details to see what is happening. I understand now that by using (a good compiled) openblas it will be sufficent for Armadillo.

23:39 < rcurtin> yeah, I guess for me the only question is whether or not getting LAPACK to embed inside of OpenBLAS is equivalent to just compiling LAPACK and OpenBLAS separately... but I am not sure

23:39 < rcurtin> I suspect you are about to be the expert on such matters :)

23:40 < shrit[m]> Finally, Mlpack have 3 dependecies, boost_po, boost_sera, and OpenBlas

23:40 < shrit[m]> After a set of testing today, if I need to add LAPACK, I will have to add CBLAS and F2C

23:42 < shrit[m]> When knn example worked, I had CLAPACK BLAS, and F2C (fortrant to C library). This is the reason I started asking my self what is the reason of OpenBlas if there is another BLAS

23:42 < rcurtin> yeah, I guess, if CLAPACK BLAS is easier to set up (and smaller), maybe it works better for the purposes of this project

23:42 < rcurtin> personally I have generally seen that OpenBLAS is more performant though

23:43 < rcurtin> (no idea what the size implication is---but I figured, if OpenBLAS is native C++, it doesn't need libgfortran, which should reduce a dependency)

23:44 < shrit[m]> I know, I use OpenBlas it is much more performant.

23:45 < shrit[m]> True F2C is a dependecy to make CLAPCK working