14:30 < himanshu_pathak[> Hey sakshamb189: zoq I am thinking of adding Multi-class svm on way to add it is using one-vs all and another can be Crammer and Singer for using one-vs all there is no need to change code of svm I can add a test and train multiple classifier in it but for Crammer and Singer I have to change whole implementation. What do you guys suggest I think going with one-vs all at this time is more sutiable?

14:30 < himanshu_pathak[> * Hey sakshamb189: zoq I am thinking of adding Multi-class svm one way to add it is using one-vs all and another can be Crammer and Singer for using one-vs all there is no need to change code of svm I can add a test and train multiple classifier in it but for Crammer and Singer I have to change whole implementation. What do you guys suggest I think going with one-vs all at this time is more sutiable?

14:42 < zoq> himanshu_pathak[: Hm, wondering what is faster, do we have some numbers?

14:44 < zoq> jeffin143[m]: Agreed, really looking forward to see all those features in a new release.

14:54 < ggalan87[m]> according to sklearn docs one-vs-rest variant is usually preferred in practice https://scikit-learn.org/stable/modules/svm.html#svm-classification

14:55 < himanshu_pathak[> zoq: I found out a paper https://www.csie.ntu.edu.tw/~cjlin/papers/multisvm.pdf this says one-vs one is good approach than others ggalan87 thanks for the info

14:55 < jeffin143[m]> I also guess one vs all is used often

14:57 < zoq> I think with that it's any easy decission, especially since we can just what you already implemented.

14:57 < himanshu_pathak[> zoq: Yup I will go with that thanksjeffin143 +1

15:17 < jeffin143[m]> @walragatver:matrix.org:

15:18 < jeffin143[m]> Did that directory delete issue was solved ?..

15:28 < walragatver[m]> Jeffin143: I didn't cross check at the time of merge but I tested it when giving you the suggestion I think it would have resolved as the code looks good.

15:57 < jeffin143[m]> Ok

16:16 < abernauer[m]> rcurtin: The mlpack.linear_svm, naming convention in R is usually associated with the S3 object sytem in R just an fyi. Alo it's reserved for method dispatch if I remember correctly.

16:45 < rcurtin> yeah, thanks for the clarification---I saw that James posted that too; I think we've reached consensus for `mlpack_linear_svm()`, which is just fine

16:45 < rcurtin> my unfamiliarity with R sometimes makes these discussions hard, because I'm trying to ensure that both (a) we can autogenerate these easily from the mlpack side and (b) it feels "native" in whatever language we're binding to

16:45 < rcurtin> but I don't typically know what (b) is in the other languages

16:49 < abernauer[m]> Yeah np. R is pretty anarchic with naming conventions. Addittionally, there is the baggage that comes from the S language, R is based on. Only reason I am familar with this stuff is because of James and reading addittional material on the language.

16:56 < abernauer[m]> rcurtin: From the perspective of an R user either solution you or Dirk proposed sounds fine. Not uncommon in my experience to use the namespace approach mlpack::det(), when writing scripts and R packages have conflicting function names.

18:56 < jeffin143[m]> rcurtin : why don't

18:56 < jeffin143[m]> We have support to save mat as a tsv file

18:56 < jeffin143[m]> And only have support for saving sp_mat

18:58 < rcurtin> I think it had to do with what Armadillo's underlying support provided

18:58 < rcurtin> basically, Armadillo only supports a handful of formats, and data::Save() just wraps that

18:58 < rcurtin> for the most part (with a couple exceptions) we don't implement the parsers ourselves

19:00 < rcurtin> if you ever wanted to add more support outside of what Armadillo supports, I would say go ahead! :-D

19:03 < jeffin143[m]> Haha

19:03 < jeffin143[m]> Ok :)