forking ublas?
"oswin krause" <[email protected]>
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <[email protected]> |
Hi, I recently came to the conclusion that for me it does not make sense to use ublas any more. I found my self reimplementing a lot of functionality that is already in-place because it was implemented poorly / can not be implemented fast in the current interface. The only reason we stay with ublas in our project is that, in theory, it is one of the most feature rich libraries out there (while having a mu in its name) and we use a lot of the functionality, especially sparse-dense matrix operations etc (and no, eigen is not an option as the interfaces are way to different to port the whole project again and eigen has a lot of restrictions for sparse matrices.) The recent discussion about the GSOC project lead me to fear that my workaround code will break, while the library itself would still not be in a state that I can just replace the workarounds with ublas core functionality. At some point I have to think about my PhD thesis and for this i would like things to get better over time (e.g. workarounds vanish and I don't need to profile ublas code all the time). I don't see this happening and I am now at the point where I know the library good enough to replace functionality directly instead of adding workarounds. So can we fork ublas? and if yes: what are the conditions? Greetings, Oswin _______________________________________________ ublas mailing list [email protected] http://lists.boost.org/mailman/listinfo.cgi/ublas Sent to: [email protected]