Jump to page: 1 2
Thread overview
BLAS implementation for D
Apr 13, 2017
data pulverizer
Apr 13, 2017
jmh530
Apr 13, 2017
data pulverizer
Apr 13, 2017
Dejan Lekic
Apr 13, 2017
Bill Baxter
Apr 13, 2017
9il
Apr 14, 2017
data pulverizer
Apr 14, 2017
jmh530
Apr 14, 2017
data pulverizer
Apr 14, 2017
bachmeier
Apr 15, 2017
Bill Baxter
April 13, 2017
I have just finished the first version of a BLAS implementation for D mostly done by code conversion from GSL's BLAS module https://github.com/dataPulverizer/dblas

It is complete functionally with respect covering all the functions implemented in BLAS. @9il has suggested that we should work to merge this library with Mir GLAS which I think is a good idea.

As the readme says the next phase is:

* Performance optimization
* Complete unit test coverage
* Type specific BLAS aliases

Thanks

p.s. Sorry for originally positing this in the General Forum, it should be here instead

---
DP
April 13, 2017
On Thursday, 13 April 2017 at 09:18:06 UTC, data pulverizer wrote:
>
> It is complete functionally with respect covering all the functions implemented in BLAS. @9il has suggested that we should work to merge this library with Mir GLAS which I think is a good idea.
>

So Mir GLAS doesn't cover all the functions? Is that the main thing that this would add?
April 13, 2017
On Thursday, 13 April 2017 at 11:29:39 UTC, jmh530 wrote:
> On Thursday, 13 April 2017 at 09:18:06 UTC, data pulverizer wrote:
>>
>> It is complete functionally with respect covering all the functions implemented in BLAS. @9il has suggested that we should work to merge this library with Mir GLAS which I think is a good idea.
>>
>
> So Mir GLAS doesn't cover all the functions? Is that the main thing that this would add?

Yes, the dblas library implements all the BLAS functions
April 13, 2017
On Thursday, 13 April 2017 at 09:18:06 UTC, data pulverizer wrote:
> I have just finished the first version of a BLAS implementation for D mostly done by code conversion from GSL's BLAS module https://github.com/dataPulverizer/dblas
>
> It is complete functionally with respect covering all the functions implemented in BLAS. @9il has suggested that we should work to merge this library with Mir GLAS which I think is a good idea.
>
> As the readme says the next phase is:
>
> * Performance optimization
> * Complete unit test coverage
> * Type specific BLAS aliases
>
> Thanks
>
> p.s. Sorry for originally positing this in the General Forum, it should be here instead
>
> ---
> DP

Really good stuff! I see no reason for calling it dblas (the package) - simple `blas` would do I think... :)


April 13, 2017
I would probably call it gnublas or gplblas something to make it clear that
it's got that aspect to it.
It can't ever really be "the one true" blas lib for all D users with that
license.

Re: merging with Mir GLAS, that seems very tricky without changing Mir
GLAS's license to GPL.
--bb

On Thu, Apr 13, 2017 at 7:56 AM, Dejan Lekic via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Thursday, 13 April 2017 at 09:18:06 UTC, data pulverizer wrote:
>
>> I have just finished the first version of a BLAS implementation for D mostly done by code conversion from GSL's BLAS module https://github.com/dataPulverizer/dblas
>>
>> It is complete functionally with respect covering all the functions implemented in BLAS. @9il has suggested that we should work to merge this library with Mir GLAS which I think is a good idea.
>>
>> As the readme says the next phase is:
>>
>> * Performance optimization
>> * Complete unit test coverage
>> * Type specific BLAS aliases
>>
>> Thanks
>>
>> p.s. Sorry for originally positing this in the General Forum, it should be here instead
>>
>> ---
>> DP
>>
>
> Really good stuff! I see no reason for calling it dblas (the package) -
> simple `blas` would do I think... :)
>
>
>


April 13, 2017
On Thursday, 13 April 2017 at 17:43:14 UTC, Bill Baxter wrote:
> I would probably call it gnublas or gplblas something to make it clear that
> it's got that aspect to it.
> It can't ever really be "the one true" blas lib for all D users with that
> license.
>
> Re: merging with Mir GLAS, that seems very tricky without changing Mir
> GLAS's license to GPL.
> --bb

Yep. Mir GLAS license would be always BSL. It is possible to use Netlib's source codes. They are always up to date and can be used for BSL.

April 14, 2017
On Thursday, 13 April 2017 at 17:43:14 UTC, Bill Baxter wrote:
> Re: merging with Mir GLAS, that seems very tricky without changing Mir
> GLAS's license to GPL.

You raise a very good point. My intention is to completely re-write each function that was based on GSL's CBLAS while upgrading the performance. Once this is done the library should be regarded as a different work ... if anyone knows more about how licenses work and can shed more light on this approach please comment. I would not want people to avoid using it in the future because of the license status.
April 14, 2017
On Friday, 14 April 2017 at 15:37:20 UTC, data pulverizer wrote:
>
> You raise a very good point. My intention is to completely re-write each function that was based on GSL's CBLAS while upgrading the performance. Once this is done the library should be regarded as a different work ... if anyone knows more about how licenses work and can shed more light on this approach please comment. I would not want people to avoid using it in the future because of the license status.

Not a lawyer, but I think if you just port it to another language it is a derived work in GPL and the ported project must also be GPL.

However, if you're completely re-writing each function, I don't know. Companies that do this would have one team look at every function and write some specs for it and have another group write it without reference to the original.
April 14, 2017
On Friday, 14 April 2017 at 16:31:24 UTC, jmh530 wrote:
> On Friday, 14 April 2017 at 15:37:20 UTC, data pulverizer wrote:
>>
>> You raise a very good point. My intention is to completely re-write each function that was based on GSL's CBLAS while upgrading the performance. Once this is done the library should be regarded as a different work ... if anyone knows more about how licenses work and can shed more light on this approach please comment. I would not want people to avoid using it in the future because of the license status.
>
> Not a lawyer, but I think if you just port it to another language it is a derived work in GPL and the ported project must also be GPL.
>
> However, if you're completely re-writing each function, I don't know. Companies that do this would have one team look at every function and write some specs for it and have another group write it without reference to the original.

Thank you for the information ... looks like I need to talk to a friendly lawyer to know for sure - if the term "friendly lawyer" is not an oxymoron :-)
April 14, 2017
On Friday, 14 April 2017 at 16:31:24 UTC, jmh530 wrote:

> Not a lawyer, but I think if you just port it to another language it is a derived work in GPL and the ported project must also be GPL.

This is correct.

> However, if you're completely re-writing each function, I don't know.

I don't think that argument would apply in this case. It would be necessary to start a new project to give it an alternative license.
« First   ‹ Prev
1 2