- WEIGHTS - I do not know a package (except my modified FANN) that could handle weights, it is important

Comment 1 (Lev): the possibility to use weights of the training events has implemented in MLPfit package

- TOPOLOGY - again, I do not know any package that could create custom nontrivial topologies

Comment 1 (Lev): SNNS has the possibility to change the topology. JETNET has a pruning algorithm

- SPEED - in physics analyses we typically use n.10^5 events with m.10^3 training epochs, it would be very useful if this could be run on any notebook/desktop in ~hour time. FANN can do that.

Comment 1 (Lev): MLPfit has optimized significantly and really fast package for the training
Comment 2 (Sasha): it would be worth comparing these two packages on one "standard" task. I don't think FANN would bit MLPfit drastically.

- NOT ONLY FEED-FORWARD - HEP applications does not include neural gas, or even cascade. One should not attempt to cover all options but rather what is useful, i.e. custom feed-forward nets with eventual feedback, eventually allowing for changes in the training data during training.

Comment 1(Sasha): if the conception (neural gas) can be useful in our problems architecture of the package should allow the structure to be included. Cascade should be added definityly.

- TRAINING ALGORITHMS - we used to minimize MSE but that does not have to be the best approach (plus even MSE should be calculated properly when using weights). RPROP or QUICKPROP should be definitely included.

Comment 1 (Lev): There are a lot of training algorithms and probably it is more important to realize the standard interface to add easily some new training algorithm in additional to what is implemented already.
Comment 2 (Sasha): I gree wuth Lev, a standard mechanism of adding new learning algos is needed. Plagin technology may help.

- LANGUAGE - should it really be based on FANN? Perhaps one could use some of its implementations but write the core from scratch. C is fast, now the question is how much C++ is slower. The obvious plus of C++ is its better flexibility and the fact that experimental PP community mostly uses C++.

Comment 1 (Lev): For the multicomponent system we probably need C++, but for the particular calculations C is faster. Will it be possible to use different languages in different places of the package?
Comment 2 (Sasha): I support C++, but this choice has one clear drawback. We can't fork neither MLPfit nor FANN...

- DOCUMENTATION - this is an extra work, and the most boring one....
- INTERFACE - HEP community uses its own programs, thus it should be easily usable straight from the (C++) code.

Comment 1 (Lev): one of the present standard is ROOT for graphical representation and event samples format
Comment 2 (Sasha): Yes, we don't need to invent a bicycle. So, I support using ROOT as GUI and XML for datacards and other files for representation of data in files (except events, certainly!)

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2009-04-26 - AlexanderSherstnev
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback