Hi Ryan, Thanks for the direction. I was working on it on the weekend. My aim is to at least run a snippet form mlpack before proceeding to proposal. My findings so far are as follows:
- JNI would be used for using C++ functions and code inside java. - We need to compile Armadillo(more on it below) and mlpack separately for each android api (version), and arm architectures (6 architectures exists for now) using specific android toolchains. - We can use either CMake or android.mk to manage the building of c++ files inside Android NDK (CMake seems better) - We can have precompiled mlpack and armadillo libraries, which can be included in NDK and used straight away (It is doable without any changes) I found that no proper fortan compiler exists for arm (I found one but it used dirty hacks). So we need to use c versions of BLAS and LAPACK to go with Armadillo. I was able to compile them to .a libraries, but armadillo is giving me issues so far. I am currently using android arm64 toolchain to compile armadillo but it is giving errors in linking my precompiled libraries. It seems that something is wrong with the Cmake script. You said that you were able to compile mlpack on your arm chromebook. How did you managed compilation or inclusion of armadillo? (I am sorry for the inconvenience but armadillo's build documentation isn't explained enough and time restricts me from going into cmake's documentation) On Fri, Mar 24, 2017 at 6:54 PM, Ryan Curtin <[email protected]> wrote: > On Fri, Mar 24, 2017 at 03:20:59AM +0500, Shoaib Zafar wrote: > > Hi Marcus! > > > > Sorry for the late reply (exams will be finally over tomorrow, Friday!) > > > > I understand your concern. I'm also not currently sure about the code > that > > would be needed. Frankly speaking, I have never worked with android NDK > > before (but I'm familiar with android studio, c++ etc). Some of the > > functions would need to be overloaded or modified to assist the user (for > > example data::load and data::save will have to be overloaded to work with > > the internal storage, current implementations would lead to internal > > storage only). To increase code, we can have a couple of classification > > apps for android with trained models, and I can write a tutorial for it > > that could be included to mlpack's website. Also, I think we should use > > android NDK's libraries as much as possible(they will be maintained and > > optimized by Google to work better with android). > > In the worst case, we'll need to reimplement some library functions if > > android studio doesn't supports it. > > > > If you say, to get a better idea, I can spend this weekend trying to get > a > > simple classification model or linear regression model to work. And then > we > > can decide whether to proceed or not :) (I am more then willing to do > > this!) > > Hi Shoaib, > > I think this could be an interesting idea. It could be helpful to spend > some time figuring out what is possible on Android and what would > require modification, so that a good proposal could be crafted that was > clear on what the goals of the project are and what modifications are > anticipated to be necessary to accomplish those goals. > > In this case it sounds like you are aiming to make the necessary > modifications so that mlpack could be used inside of Android > applications, which I think would be an interesting project. If we can, > at the end of the summer, have a nice set of documentation that shows > someone who wants to do machine learning inside their Android app how to > use mlpack, I think this could be really compelling. > > Thanks, > > Ryan > > -- > Ryan Curtin | "Are you or are you not the Black Angel of Death?" > [email protected] | - Steve >
_______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
