I find your idea to port the current version or at least the CORE of CLA into C++ or ANSI C and clean it as more as possible is very good.
It will be better for newbies to understand und test it in his framework/application.
But othercodes in the implementation like visualisation, statistics etc are not really useful for the final applications, but they are very usefull for understanding how CLA works, also for further development.
For this reason, I would like to recommend to let those codes in our implemenation, but we should have possibilities to turn them on/off by compiling.
To motivate more people to work with our openHTM we need to write more codes for
decoding common data inputs (at least 1D-data, 2D-Data like images) into sparse binary description
convert the openHTM data format back into the user data format
What do you think?
Regards
Hoa Nam
----- Ursprüngliche Nachricht -----
Von: David Ragazzi
Gesendet: 31.05.13 18:28 Uhr
An: [openhtm:discussion]
Betreff: [openhtm:discussion] New directions to OpenHTM implementation
Hi all, As you know, last days I reviewed the CLA white paper for convert the pseudo-code to OO approach and include UML diagrams in order to it easier to understand. However in meantime I had some ideas for our project. First of all, I realized that our CLA implementation became complex enough to 'newbies' take a long time to understand our imlementation and finally contribute. I understand that several changes were necessary but much others we could avoid. I believe we should simplify it and leave it closer to CLA white paper. When I converted pseudocode to OO approach, I noted several code of our current implementation either is redudant or is not fully useful (statistics, for example) or its naming is different from white paper. White paper is not difficult to understand (mainly when the pseudocode is object oriented). So if we leave our implementation closer to original pseudocode, several people could contribute and the learning curve would decrease once the documentation will be the same. For example, properties like 'IsActive', 'IsActiveWasLearning' or methods like 'ProcessSegments', and many others I found, performs redudant actions that instead from help to understand let us with the sensation that the code is more complex and bigger than it seems. With this in mind, I decided implement my own CLA implementation from scratch using the same naming and structure from white paper in order to test if we could have a simpler and smaller code. Yesterday I finished spatial pooler. I would say that the code is very small and clean (as closer to original as possible, including the exact white paper descriptions and some code borrowed from our current). So, one interesting thing is we refactored the code having the White paper as model. The other thing is that maybe is the time to we already have CLA in a language like C++. The claims for comunity members are fully valid and so we will have more people working it (softnhard, for example). I also know that many of us like Michael, Barry, also has C++ implementations and keeping working them. So the idea is the CLA being a static library in native code (keeping Visual Studio as IDE but automatically compiling it with GCC or other compiler from own VS through compilation params). I believe that all us here won't have problems with C++ and even I could perform this conversion. From I tested, we can have this static library without need use explicit pointers and others, so the code will keep nice and clean like C# (I made some experiments and visually implementations in C# and C++ are very similar). Having this said I would like know your opinions about it (developer team and members). Best, David --- New directions to OpenHTM implementation --- Sent from sourceforge.net because you indicated interest in
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear David,
I find your idea to port the current version or at least the CORE of CLA into C++ or ANSI C and clean it as more as possible is very good.
It will be better for newbies to understand und test it in his framework/application.
But othercodes in the implementation like visualisation, statistics etc are not really useful for the final applications, but they are very usefull for understanding how CLA works, also for further development.
For this reason, I would like to recommend to let those codes in our implemenation, but we should have possibilities to turn them on/off by compiling.
To motivate more people to work with our openHTM we need to write more codes for
What do you think?
Regards
Hoa Nam
----- Ursprüngliche Nachricht -----
Von: David Ragazzi
Gesendet: 31.05.13 18:28 Uhr
An: [openhtm:discussion]
Betreff: [openhtm:discussion] New directions to OpenHTM implementation
Hi all, As you know, last days I reviewed the CLA white paper for convert the pseudo-code to OO approach and include UML diagrams in order to it easier to understand. However in meantime I had some ideas for our project. First of all, I realized that our CLA implementation became complex enough to 'newbies' take a long time to understand our imlementation and finally contribute. I understand that several changes were necessary but much others we could avoid. I believe we should simplify it and leave it closer to CLA white paper. When I converted pseudocode to OO approach, I noted several code of our current implementation either is redudant or is not fully useful (statistics, for example) or its naming is different from white paper. White paper is not difficult to understand (mainly when the pseudocode is object oriented). So if we leave our implementation closer to original pseudocode, several people could contribute and the learning curve would decrease once the documentation will be the same. For example, properties like 'IsActive', 'IsActiveWasLearning' or methods like 'ProcessSegments', and many others I found, performs redudant actions that instead from help to understand let us with the sensation that the code is more complex and bigger than it seems. With this in mind, I decided implement my own CLA implementation from scratch using the same naming and structure from white paper in order to test if we could have a simpler and smaller code. Yesterday I finished spatial pooler. I would say that the code is very small and clean (as closer to original as possible, including the exact white paper descriptions and some code borrowed from our current). So, one interesting thing is we refactored the code having the White paper as model. The other thing is that maybe is the time to we already have CLA in a language like C++. The claims for comunity members are fully valid and so we will have more people working it (softnhard, for example). I also know that many of us like Michael, Barry, also has C++ implementations and keeping working them. So the idea is the CLA being a static library in native code (keeping Visual Studio as IDE but automatically compiling it with GCC or other compiler from own VS through compilation params). I believe that all us here won't have problems with C++ and even I could perform this conversion. From I tested, we can have this static library without need use explicit pointers and others, so the code will keep nice and clean like C# (I made some experiments and visually implementations in C# and C++ are very similar). Having this said I would like know your opinions about it (developer team and members). Best, David --- New directions to OpenHTM implementation --- Sent from sourceforge.net because you indicated interest in