Hi, Thanks for input
We have both possibilities, from scratch or/and using a library, still an open topic. For now either way we chose, I think we would be limited to a few GB's of data, but we can extend it later if we start with this idea in mind. IMHO making anything to work with hundreds of GB's of data could be alone another project :) My idea is to have a scilab interface which is how it's organized and can be used/called, and how it works in the backend could be scilab code, C/C++ code or calling other libraries. Somebody have some idea how to handle this project in a software > engineering perspective? > Just to ensure the tests and code quality. 1) Define our interface (most important thing), here I think who uses most the feature should chose. 2) Start with simple algorithms, but working 100% inside our interface. 3) Demos, tests and documentation for everything 4) Repeat 2 and 3. After doing 2 and 3 for the first time we will be able to advance faster. Then from the Scilab programmers point of view, if we were using the JIMS > or PIMS, at the ends the Scilab codes would be very much looks like Python > or Java style, unless we wrote another macros to wrap all these into > Scilab style. > Not sure what would be more convenient to users, but I would prefer to wrap everything inside scilab to make a simpler interface. So far I think the C/C++ API might be the most "seamless" integrated into > Scilab, which we could utilizing parts of the C/C++ libraries while others > work in Scilab If we have our own interface, using C/C++, Python or Java could make difference only in performance, but all those lib have their core in C/C++, so I would choose simplicity for now. > Finally as for the GPU usage concern, using libs could have solve this > depending on the lib being used. > I see GPU support being an option after we have something solid working already on CPU. Best, Caio SOUZA
_______________________________________________ dev mailing list [email protected] http://lists.scilab.org/mailman/listinfo/dev
