Subject: Re: [ublas] forking ublas?
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2013-04-10 14:04:47
I don't think there are any requirements in place in order to fork
uBlas, you can just go ahead and make your own project based on it. I
suspect thought that the maintainers would be happy to provide a
convenient versioning environment (through github maybe?) for people
that want to contribute in say providing new algorithms or improving on
existing ones, while retaining the core functionality.
Can you give an example of what functionality you had to rewrite?
On 04/07/2013 01:50 AM, oswin krause wrote:
> 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
> So can we fork ublas? and if yes: what are the conditions?
> ublas mailing list
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]