|
|
Ublas : |
Subject: Re: [ublas] forking ublas?
From: David Bellot (david.bellot_at_[hidden])
Date: 2013-04-13 13:19:30
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_at_[hidden]>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_at_[hidden]
>> http://lists.boost.org/**mailman/listinfo.cgi/ublas
>> Sent to: athanasios.iliopoulos.ctr.gr@**nrl.navy.mil<athanasios.iliopoulos.ctr.gr_at_[hidden]>
>>
>
> ______________________________**_________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/**mailman/listinfo.cgi/ublas
> Sent to: david.bellot_at_[hidden]
>