verne.freenode.net changed the topic of #mlpack to: http://www.mlpack.org/ -- We don't respond instantly... but we will respond. Give it a few minutes. Or hours. -- Channel logs: http://www.mlpack.org/irc/
< zoq>
sumedhghais: I timed boost variant against boost visitor some weeks ago and could see any obvious performance improvements. The downside with boost variant is that it makes the construction of complex architectures really complicated like if you split your architecture into branches and merge them later on.
< rcurtin>
zoq: do you mean "couldn't see any obvious performance improvements"?
< zoq>
ah yeah, right, thanks for the correction
< rcurtin>
:)
< rcurtin>
when you say that you tested boost variant against boost visitor... I guess I am a little confused, I thought that the visitor paradigm was necessary to use boost::variant classes
< zoq>
you are right once again, I was talking about variadic templates and std::tie against boost variant ...
< rcurtin>
ah, right
< rcurtin>
and the variadic template / std::tie approach is a lot closer to what Sumedh suggested in his code that he sent us some months back I think
< rcurtin>
this is what I would have expected... but I can't say that I understand exactly what is going on with boost::visitor... it is very complicated
< rcurtin>
every time I approach it, I can get to a point where I understand it, but then a week later I have forgotten the details :)
< zoq>
I think variadic templates is what sumedh has in mind but not sure, I'll have to take a look at the code. I agree boost variant isn't really that easy to get, some parts are just magic.
< rcurtin>
yeah, variadic templates seems to be what he does in his code:
< rcurtin>
template<class... LayerType> class NeuralNetwork
< rcurtin>
if I am remembering right that is what the ANN code originally was structured like
< zoq>
yes, I guess we could support both strategies, if someone likes to take a shot at it and finds some reasonable performance improvements.
< rcurtin>
if you saw no performance difference between the two approaches, I don't know if it's worth the time to pursue
< rcurtin>
so I would think that only in the case that Sumedh can show some huge runtime difference between the approaches, only then would it be worth considering a giant refactor of the code
< rcurtin>
but I suspect that boost::variant has enough magic inside of it that there won't be a big difference
< zoq>
yeah, probably it is not worth the effort, but I guess let's see what Sumedh finds out.
< rcurtin>
example auto-generated documentation for command-line programs and Python bindings: https://pastebin.com/TH6zakCL
< rcurtin>
with this writing the PROGRAM_INFO() string is a little bit harder and you have to use auxiliary functions, but the nice thing is that the documentation will be auto-generated for all languages
< zoq>
cool, I didn't thought about the code examples in the documentation, nice to see you also map the code snippets
< rcurtin>
yeah, I will have to write a guide on "how to write a PROGRAM_INFO() string"
< rcurtin>
since now you have to be careful with the language
< rcurtin>
for a Python binding, the output parameters come back as the return value, in a dict
< rcurtin>
but for a command-line binding, where to save the output parameters is specified as input
< rcurtin>
so you have to be careful and write things like "the matrix may be saved with the (parameter name) output parameter", and not, e.g., "the file to save the matrix to is specified with the (parameter name) parameter"
< zoq>
hm, it's not that simple as before but I guess you get used it.
< rcurtin>
yeah, fortunately, it is a thing that you only have to write once
< zoq>
right and it's still simple enough
sumedhghaisas has joined #mlpack
mikeling has quit [Quit: Connection closed for inactivity]