|
|
Ublas : |
Subject: [ublas] forking ublas?
From: oswin krause (oswin.krause_at_[hidden])
Date: 2013-04-07 01:50:11
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