Hi,

forking ublas might not be the worst idea but people would be very confused. So maybe it's not the best idea but a uBLAS 2 is presumably the way to go. Which means will advertise the fact that the new version is not fully compatible with the previous one.

Like many other, I prefer to program with the simplicity of ublas and I'd love to preserve it as much as possible but we all acknowledge the fact that, even the interface, not to say about the core, needs serious love. Hence the GSOC project.

I don't think the GSOC project will be enough to reach this goal. One thing is sure, the kernel needs to be improved/rewritten in order to catch more functionalities and new technologies.

That was for the political part of my email :-D

Yes, we can have a repository for new functionalities and put in place a review system to quickly integrate new functionalities. There is one on sourceforge and I just created a new one on github as it's the new guy in town (https://github.com/uBLAS/uBLAS)

Best,
David




On Wed, Apr 10, 2013 at 7:04 PM, Nasos Iliopoulos <nasos_i@hotmail.com> wrote:
Oswin,
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?

Best,
Nasos




On 04/07/2013 01:50 AM, oswin krause wrote:
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
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com