10:11 < JMarler> Hi all, In need of a quick bit of advice regarding the internals of libarmadillo matricies - specifically in the naive bayes classifier

10:12 < JMarler> In the Classify method of mlpacks NBC

10:12 < JMarler> Am I right in thinking lines like the following

10:12 < JMarler> arma::mat rhs = -0.5 * arma::diagmat(invVar.col(i)) * diffs;

10:12 < JMarler> arma::vec exponents(diffs.n_cols);

10:13 < JMarler> will be allocating on the heap for the arma::vec and arma::mat objects ?

10:13 < JMarler> In other words is heap memory being requested from the OS in the Classify method ?

10:14 < JMarler> Apologies I'm not entirely sure how armadillo allocated memory internally. Assuming it just uses a std::vector or similar

10:14 < JMarler> Suspect this is the case

10:16 < mentekid> JMarler: yes, armadillo uses heap memory to store the elements of vectors and matrices

10:17 < mentekid> but you don't need to delete/free anything, it does that itself

10:18 < JMarler> Blast

10:18 < JMarler> Assumed that was the case

10:18 < JMarler> I'm attempting to use some of the various classifiers in a real time audio/callback thread and heap allocation is a big no go.

10:20 < JMarler> Looking at the code for the NBC can anyone confirm for me whether I'm right in thinking that the various Mat and Vec objects could be potentially allocated at construction time of the NBC ?

10:20 < JMarler> Willing to alter the code for my own use but I don't want to go flying along on a fruitless endeavour

10:22 < mentekid> Maybe someone's more qualified to answer that for you (I'm new here) but I think since it's all on the heap, they are allocated at construction time, not compile time

10:22 < mentekid> I think only arma::mat::fixed grabs memory at compilation

10:23 < JMarler> Thanks mente kid.

10:24 < JMarler> My issue is that I am calling the NBC's Classify method directly in my audio callback

10:24 < JMarler> Looking at the code for the NBC there are lines like the following in the Classify method:

10:24 < JMarler> arma::vec exponents(diffs.n_cols);

10:25 < JMarler> Which I am assuming means the object above (arma::vec exponents) is allocating memory for its elements on the heap

10:26 < JMarler> On a real time audio thread this can cause drop outs as it potentially means the thread could end up waiting for the OS to actually serve up the heap space

10:26 < JMarler> The audio thread needs to run in constant/deterministic time. So requesting memory from the OS is tabboo.

10:28 < JMarler> I'm still in my early days as far as Machine Learning is concerned and this is for an academic project so I guess my question for anyone that may be able to answer is looking at the NBC Classify method would I be right in thinking that objects like arma::vec exponents could potentially be constructed outside of the Classify method ? i.e. in the NBC class's constructor ?

10:51 < JMarler> For example the implementation would probably involve providing an option to construct and NBC with a known / fixed training set size to avoid dynamically allocating the training set matrix by calling functions like:

10:52 < JMarler> results.setSize(&data.n_cols);

10:53 < JMarler> Basically I'd just like to sanity check the purely changing the boiler plate / memory allocation scheme won't affect the internals of the classification algorithm.

10:54 < JMarler> I could possibly add a classify method with an additional argument flag like "fixed" or "realtime":

10:54 < JMarler> Classify(const MatType& data, arma::Row<size_t>& results, bool fixedSize)

11:02 < JMarler> Hi all, Apologies got cut off

11:02 < JMarler> Any answers to previous questions most appreciated

11:04 < mentekid> JMarler: I'm not sure how to answer these since I'm new, maybe some of the other guys will be able to help you

11:05 < mentekid> Because of the timezones they might be sleeping at the moment though so you might have to wait a bit :)

11:05 < JMarler> mentekid: No problem. Thanks for the input regardless

11:24 < JMarler> I've noticed libarmadillo has an ARMA_MAT_PREALLOC flag defined

11:25 < JMarler> This internally I believe sets: static const uword mat_prealloc = 16;

11:26 < JMarler> In fact...ignore that. Being slow, ARMA_MAT_PREALLOC is still irrelevant for my usage

12:43 < JMarler> Starting to look at making some of these changes now. Would this be something that would be of use to mlpack ? i.e. as a pull request.

12:44 < JMarler> It's a fairly significant change so I may be better just moving away from mlpack and attempting to roll out my own routines for the audio domain

12:47 < JMarler> I think it could have some potential though. It could be of big use to the audio community as users of frameworks like JUCE for audio analysis purposes amongst others.

13:14 < rcurtin> JMarler: I'm not sure there's an easy way to get mlpack to run without allocating memory all over the place

13:14 < rcurtin> Armadillo already will allocate all over the place for linear algebra operations

13:15 < JMarler> rcurtin: Thanks for the response

13:15 < JMarler> Sorry I'm not in the know how in regards to the internals of armadillo

13:16 < rcurtin> so it may be somewhat hard to adapt the NaiveBayesClassifier class to not allocate anything

13:16 < rcurtin> I have to wonder if maybe the easier approach is to modify Armadillo only

13:16 < rcurtin> and basically write your own memory manager

13:16 < JMarler> So regardless of whether the memory for all the various matrices and vectors is being allocated at object construction you would say armadillo would still alloc internally ?

13:17 < rcurtin> there is a function there, memory::acquire(), that is basically a wrapper around the new operator... maybe it could be modified to take memory that you had preallocated

13:17 < rcurtin> hang on... phone call

13:17 < JMarler> It would be fine for the NBC to dynamically allocate for my problem just not in the Train() and Classify() methods, it would have to pre-allocate all the Mat and Col/Vec variables in the NBC constructor

13:19 < JMarler> Maybe it's too specific a use case and I'm going to have to scale things down to use my own classifiers/routines (mlpack just seemed the best way to get things up and running quickly at the time)

13:20 < rcurtin> unfortunately I think I agree that it's too specific; I don't really want to change the NBC class to do that, unless we change all classes inside of mlpack to function like that (for consistency), and that would be a huge undertaking

13:20 < rcurtin> I think for your use case, you might be best off just modifying mlpack and using it

13:21 < rcurtin> but a thing to be careful about is that the expressions of Armadillo may still allocate memory, like:

13:21 < rcurtin> arma::mat diffs = data - arma::repmat(means.col(i), 1, data.n_cols);

13:21 < rcurtin> I am not sure, but it's possible that the repmat call may allocate memory

13:21 < rcurtin> (ideally it shouldn't, the template metaprogramming should take care of it, but it's possible that it doesn't)

13:22 < JMarler> I thought it would be the assignment itself as figured arma::mat probably allocates space for its elements internally regardless ?

13:22 < rcurtin> yeah; so there are multiple possible allocations in that statement

13:22 < rcurtin> first, the memory for diffs has to be allocated

13:22 < rcurtin> and memory may be allocated for the repmat call

13:23 < rcurtin> the reason I say "may" and not "will" is because it depends entirely on how good the template metaprogramming is inside armadillo

13:23 < rcurtin> it's possible (and I am hopeful) that the code actually generated will not allocate any extra memory for the repmat call, by just looping over that column means.col(i) repeatedly

13:23 < JMarler> Yeah that was my assumption. Hence it'd mean all Mat and Vecs in those routines being member vars which have their mem allocated in the NBC constructor. For the sake of safety it'd have to be that way

13:23 < rcurtin> but it's hard to know without diving into the Armadillo codebase and that code is... difficult :)

13:24 < JMarler> No problem. I figured this was going to be the case

13:24 < rcurtin> yeah

13:24 < rcurtin> so this is why I thought that maybe it might be easier to modify Armadillo to have its own allocator

13:24 < JMarler> Shall have to decide whether to just mod mlpack for myself or go it alone entirely

13:24 < rcurtin> like, at the beginning of the program, allocate a big chunk of memory, and then in memory::acquire(), just grab some of that memory

13:25 < rcurtin> I think the Armadillo memory allocations are the vast majority of dynamic allocations inside of the classes

13:25 < JMarler> To be honest the research project is likely to use a limited number of classifier types, maybe NBC, Kmeans, SVM and one other so going it alone might have to be the way forward.

13:26 < JMarler> Yeah. It might be possible to use Armadillo still but I'm starting to lean more towards a couple small scale classes given all of these issues.

13:26 < JMarler> Thanks a lot for the input anyways Ryan

13:26 < rcurtin> sure, I'm sorry it's not working straight out of the box :)

13:27 < rcurtin> I have to run... I'll be back later today

13:28 < JMarler> Ahhhhh who knows. Maybe in retirement I might have the time to attempt that kind of pull request.........thankfully I'm 26 so unlikely to ever put the mlpack team through the requests!

13:28 < JMarler> no problem

13:28 < JMarler> cheers

13:30 < rcurtin> :)