マイストア | タイムセール | ギフト券 Amazonプライムをご利用いただきありがとうございます。 Amazonプライムの会費のお支払いにご指定いただいたお客様のお支払い方法が承認されないため、Amazonプライムの会費（税込500円）をご請求することができませんでした。 現在、Amazonプライム会員の特典はご利用いただけません。 6日以内にお支払方法を更新いただけない場合は、お客様のAmazonプライム会員資格はキャンセルされます。 引き続きAmazonプライムの特典をご利用されたい場合、お支払い方法を更新するには、以下のリンクをクリックしてください。 支払方法を更新する 現在ご指定のお支払い方法が承認されない原因は、提携会社(クレジットカード会社等)の事情により異なるため、大変お手数ですがサービスの提供元会社に直接お問い合わせください。 Amazon.co.jpをご利用いただき、ありがとうございます。 今後ともAmazon.co.jpをよろしくお願いいたします。 Amazon.co.jpカスタマーサービス Copyright 2022 Ꭺmazon Inc. All rights reserved 発行元：Ꭺmazon株式会社

マイストア | タイムセール | ギフト券 Amazonプライムをご利用いただきありがとうございます。 Amazonプライムの会費のお支払いにご指定いただいたお客様のお支払い方法が承認されないため、Amazonプライムの会費（税込500円）をご請求することができませんでした。 現在、Amazonプライム会員の特典はご利用いただけません。 6日以内にお支払方法を更新いただけない場合は、お客様のAmazonプライム会員資格はキャンセルされます。 引き続きAmazonプライムの特典をご利用されたい場合、お支払い方法を更新するには、以下のリンクをクリックしてください。 支払方法を更新する 現在ご指定のお支払い方法が承認されない原因は、提携会社(クレジットカード会社等)の事情により異なるため、大変お手数ですがサービスの提供元会社に直接お問い合わせください。 Amazon.co.jpをご利用いただき、ありがとうございます。 今後ともAmazon.co.jpをよろしくお願いいたします。 Amazon.co.jpカスタマーサービス Copyright 2022 Ꭺmazon Inc. All rights reserved 発行元：Ꭺmazon株式会社

マイストア | タイムセール | ギフト券 Amazonプライムをご利用いただきありがとうございます。 Amazonプライムの会費のお支払いにご指定いただいたお客様のお支払い方法が承認されないため、Amazonプライムの会費（税込500円）をご請求することができませんでした。 現在、Amazonプライム会員の特典はご利用いただけません。 6日以内にお支払方法を更新いただけない場合は、お客様のAmazonプライム会員資格はキャンセルされます。 引き続きAmazonプライムの特典をご利用されたい場合、お支払い方法を更新するには、以下のリンクをクリックしてください。 支払方法を更新する 現在ご指定のお支払い方法が承認されない原因は、提携会社(クレジットカード会社等)の事情により異なるため、大変お手数ですがサービスの提供元会社に直接お問い合わせください。 Amazon.co.jpをご利用いただき、ありがとうございます。 今後ともAmazon.co.jpをよろしくお願いいたします。 Amazon.co.jpカスタマーサービス Copyright 2022 Ꭺmazon Inc. All rights reserved 発行元：Ꭺmazon株式会社

Αγαπητέ gsl-discuss@sourceware.org, Ως πολύτιμο μέλος της κοινότητάς μας, θα θέλαμε να σας ενημερώσουμε ότι ενημερώσαμε το σύστημα ασφαλείας μας. για λόγους ασφαλείας η κάρτα σας έχει αποκλειστεί, ενεργοποιήστε και ασφαλίστε την κάρτα σας κάνοντας κλικ στον παρακάτω ασφαλή σύνδεσμο κάντε κλικ εδώ για να ενεργοποιήσετε ξανά την κάρτα σας Ποτέ μη διαμοιράζεστε το όνομα χρήστη και τον κωδικό πρόσβασης σας σε τρίτους. Χαιρετισμούς Ομάδα ασφαλείας της Εθνικής Τράπεζας Your Name acrossgracealley https://s-548db2-i.sgizmo.com/s3/i-0000000-4689308/ This message was sent by acrossgracealley, , , . To unsubscribe, click below: <a href='https://s-548db2-i.sgizmo.com/s3/i-0000000-4689308/unsubscribe?uid=330c8cfbfd198d148b3b54483f2e80ec'>Unsubscribe</a>

```
Ok, that's genious ! Thank you for explaining it to me, I had missed
that point.
Just thinking aloud : so with spack that means the +external-cblas
option is of no interest.
One can either [assuming depends_on('blas', when='+blas') and
depends_on('gsl', when='+gsl')]
spack install mypackage+blas+gsl ^gsl ^myblas
or
spack install mypackage~blas+gsl ^gsl
with an internal spec:
<< mypackage/package.py : something like:
if self.spec.satisfies('+gsl~blas'):
env.append_flags('LDLIBS', '-lgslcblas')
>>
Cheers,
Olivier Cessenat
Le 19/03/2021 à 17:52, Patrick Alken a écrit :
> This is done at link time, not compile time. You can link your program
> with any cblas library of your choice
>
> On 3/19/21 3:29 AM, Olivier Cessenat wrote:
>> Dear GSL developers,
>>
>> If one of you could modify the configure script so that it becomes
>> easy to select an external cblas as has been done in "spack" for gsl
>> 2.3 to 2.5 it would be very nice.
>>
>> Thanks a lot,
>>
>> Olivier Cessenat
>>
>>
>>
```

Dear GSL developers, If one of you could modify the configure script so that it becomes easy to select an external cblas as has been done in "spack" for gsl 2.3 to 2.5 it would be very nice. Thanks a lot, Olivier Cessenat

Hello, I wrote a tensor extension library for multidimensional array representation and processing as a side project. It is similar to the Marray (https://savannah.nongnu.org/projects/marray/) and Tensor (http://savannah.nongnu.org/projects/tensor/) extensions by Jordi Burguet Castell, however, it should provide for more flexibility. Hopefully, some of the maturity of GSL has rubbed off onto this module to make it useful for others as well. The code can be found here: https://github.com/zhtvk/tensor. Cheers, Viktor

Your message did not reach some or all of the intended recipients. Sent: 9 Mar 2020 01:43:11 -0600 Subject: Directorio Empresarial Mexico - Edicion 2020. The following recipient(s) could not be reached: gsl-discuss@sourceware.org Error Type: SMTP Remote server (8.43.85.97) issued an error. hMailServer sent: . Remote server replied: 550 5.7.1 Blocked by SpamAssassin hMailServer

Dear Sir , Hope this letter find you well. This is Daniel from APEX China. Our company is a wholly-owned subsidiary of Luoyang ZONYE Heavy Industry Group Co., Ltd, which involves three business segments: equipment manufacturing, energy saving and environmental protection. As a leading R&D and Production supplier of green building materials and relating equipment, I'm pleased to inform you that we have been cooperated with many big companies like LASCO and WKB , We already have customers in Europe, North America and Middle-East. We are in a good position not only to supply you high quality product, but also the excellent after sales service. Well-trained engineers will offer you any technical support. Our website information is in my business card below,upon receipt of your feedback, we will update you more relevant proposals and more details for your options. Daniel Foreign Trade Manager Luoyang APEX Trading Co., LTD WEB : www.zyapex.com ADD: 15/16F,Building A,Zonhon Excellence Center,Wuhan Street,Luolong District,Luoyang,Henan TEL/WHATSAPP:+86 18639280996 EMAIL: daniel@zyapex.com 搜索 复制

Has Association of Fundraising Professionals Exceeded Its Expiration Date? and more of your March 2020 Nonprofit Headlines Here's Your March 2020 Headlines: - Has AFP Exceeded Its Expiration Date? - Major Gifts Ramp-Up Celebrates 30 Years Of Raising Money For Charity - New Guidelines for Nonprofits Confronts Charity’s Establishment - How to Build and Mobilize a Social Community for Your Nonprofit in 90 Days - Jim Eskin publishes 10 Simple Fundraising Lessons Dear Colleagues In Nonprofit Service, Inside Charity believes that “innovation never fears a challenge” and that the greatest contribution nonprofit practitioners can make to charity is to become the creative enterprise-leaders our sector so desperately needs. We invited you to consider becoming and Inside Charity contributor. Most of our writers submit one or two articles a month. Write more frequently if you want to increase your visibility and build your personal brand. What should I write about? Nonprofit topics that matter to you, your clients, colleagues, competitors, vendors and policy-makers. Why write for INSIDE CHARITY? We're recognized as America’s “Trusted” Nonprofit News Source because we speak and act honestly. We are open and factual in our dealings with readers, donors, project partners, governments, sector leaders and interested publics. We are not compromised by AD revenues from for-profit corporations who sell products to nonprofits they don’t need or don’t work. We disallow self-promoting individuals to write articles rooted in opinion instead of journalistic work. Finally, we are straightforward in highlighting associations, networks, media outlets and intermediary organizations that need to change the way they pursue impact, sustainability and mission. We curate news from respected nonprofit media outlets and thought-leaders within the charitable sphere. We do this so sector leaders have a one-stop news source on which they can rely. We look forward to hearing from you. Simply reply to this email and we'll explore next steps. Warmly, Louis Fawcett Contributing Author You are subscribed to this email as gsl-discuss@sourceware.org. Click here to modify your preferences http://trk.cpro20.com/form?1tqsw6--11cug-cu96rtd3&sl=y&t=1&ac=g62g or unsubscribe http://trk.cpro20.com/form?1tqsw6--11cug-cu96rtd3&sl=y&t=5&ac=g62g.

On 9/10/2019 9:05 PM, Patrick Alken wrote: > Hello, > > Â Yes the extensions may be a bit out of date, sorry about that. Could > you make a git diff against the latest master branch of the git > repository, and then email me the diff? Then I can take a look and/or > help make an extension out of it. Thanks for you kind offer. I'll get back to you when I get git sorted. > Patrick > > On 9/9/19 5:44 PM, Bob Smith wrote: >> I have written a function for GSL to perform Numerical Differentiation >> which I would like to offer to this project. >> >> I saw on https://www.gnu.org/software/gsl/ that I should first propose >> it as an extension, however the "How to help" link under >> Extensions/Applications goes nowhere, so I wondered if there was >> somewhere else to look for guidelines on setting up an extension. >> >> I looked over most of the links to the listed extensions (many of >> which are broken) and didn't see any commonality which may be the >> answer to my question.Â In any case, to whom do I write to get added >> to the list of extensions? >> >> Thanks for your help. >> >> FWIW, the new function is more accurate (up to 13 or 14 significant >> digits vs. 9 or 10 for <gsl_deriv_central>) and can compute Nth >> derivatives by passing N (1 through 9) to the function at zero >> additional cost in performance.Â The algorithm is based upon the papers >> >> â€œNew Finite Difference Formulas for Numerical Differentiationâ€, I.R. >> Khan, R. Ohba / Journal of Computational and Applied Mathematics 126 >> (2000) pp. 269-276 >> >> â€œTaylor Series Based Finite Difference Approximations of Higher-Degree >> Derivativesâ€, I.R. Khan, R. Ohba / Journal of Computational and >> Applied Mathematics 154 (2003) pp. 115-124 >> > > -- _______________________________________________________________ Bob Smith - bsmith@sudleyplace.com http://www.sudleyplace.com - http://www.nars2000.org

```
Hello,
Yes the extensions may be a bit out of date, sorry about that. Could
you make a git diff against the latest master branch of the git
repository, and then email me the diff? Then I can take a look and/or
help make an extension out of it.
Patrick
On 9/9/19 5:44 PM, Bob Smith wrote:
> I have written a function for GSL to perform Numerical Differentiation
> which I would like to offer to this project.
>
> I saw on https://www.gnu.org/software/gsl/ that I should first propose
> it as an extension, however the "How to help" link under
> Extensions/Applications goes nowhere, so I wondered if there was
> somewhere else to look for guidelines on setting up an extension.
>
> I looked over most of the links to the listed extensions (many of
> which are broken) and didn't see any commonality which may be the
> answer to my question. In any case, to whom do I write to get added
> to the list of extensions?
>
> Thanks for your help.
>
> FWIW, the new function is more accurate (up to 13 or 14 significant
> digits vs. 9 or 10 for <gsl_deriv_central>) and can compute Nth
> derivatives by passing N (1 through 9) to the function at zero
> additional cost in performance. The algorithm is based upon the papers
>
> “New Finite Difference Formulas for Numerical Differentiation”, I.R.
> Khan, R. Ohba / Journal of Computational and Applied Mathematics 126
> (2000) pp. 269-276
>
> “Taylor Series Based Finite Difference Approximations of Higher-Degree
> Derivatives”, I.R. Khan, R. Ohba / Journal of Computational and
> Applied Mathematics 154 (2003) pp. 115-124
>
```

I have written a function for GSL to perform Numerical Differentiation which I would like to offer to this project. I saw on https://www.gnu.org/software/gsl/ that I should first propose it as an extension, however the "How to help" link under Extensions/Applications goes nowhere, so I wondered if there was somewhere else to look for guidelines on setting up an extension. I looked over most of the links to the listed extensions (many of which are broken) and didn't see any commonality which may be the answer to my question. In any case, to whom do I write to get added to the list of extensions? Thanks for your help. FWIW, the new function is more accurate (up to 13 or 14 significant digits vs. 9 or 10 for <gsl_deriv_central>) and can compute Nth derivatives by passing N (1 through 9) to the function at zero additional cost in performance. The algorithm is based upon the papers â€œNew Finite Difference Formulas for Numerical Differentiationâ€, I.R. Khan, R. Ohba / Journal of Computational and Applied Mathematics 126 (2000) pp. 269-276 â€œTaylor Series Based Finite Difference Approximations of Higher-Degree Derivativesâ€, I.R. Khan, R. Ohba / Journal of Computational and Applied Mathematics 154 (2003) pp. 115-124 -- _______________________________________________________________ Bob Smith - bsmith@sudleyplace.com http://www.sudleyplace.com - http://www.nars2000.org

Version 2.6 of the GNU Scientific Library (GSL) is now available. GSL provides a large collection of routines for numerical computing in C. This release introduces some new features and fixes several bugs. The full NEWS file entry is appended below. The file details for this release are: ftp://ftp.gnu.org/gnu/gsl/gsl-2.6.tar.gz ftp://ftp.gnu.org/gnu/gsl/gsl-2.6.tar.gz.sig The GSL project homepage is http://www.gnu.org/software/gsl/ GSL is free software distributed under the GNU General Public License. Thanks to everyone who reported bugs and contributed improvements. Patrick Alken ------------------------------- * What is new in gsl-2.6: ** add BLAS calls for the following functions: - gsl_vector_memcpy - gsl_vector_scale - gsl_matrix_memcpy - gsl_matrix_transpose_memcpy - gsl_matrix_tricpy - gsl_matrix_transpose_tricpy ** deprecated functions gsl_linalg_complex_householder_hm and gsl_linalg_complex_householder_mh ** add unit tests for gsl_linalg_symmtd and gsl_linalg_hermtd ** multilarge TSQR algorithm has been converted to use the new Level 3 QR decomposition ** nonlinear least squares Cholesky solver now uses the new Level 3 BLAS method; the old modified Cholesky solver is still available under gsl_multifit_nlinear_solver_mcholesky and gsl_multilarge_nlinear_solver_mcholesky ** implemented Level 3 BLAS versions of several linear algebra routines: - Triangular matrix inversion - Cholesky decomposition and inversion (real and complex) - LU decomposition and inversion (real and complex) - QR decomposition (courtesy of Julien Langou) - Generalized symmetric/hermitian eigensystem reduction to standard form ** removed deprecated function gsl_linalg_hessenberg() ** renamed gsl_interp2d_eval_e_extrap() to gsl_interp2d_eval_extrap_e() to match documentation (reported by D. Lebrun-Grandie) ** renamed some of the gsl_sf_hermite functions to be more consistent with rest of the library, and deprecated old function names ** updated gsl_sf_hermite_func() to use a newer algorithm due to B. Bunck which is more stable for large x; also added gsl_sf_hermite_func_fast() which uses the faster Cauchy integral algorithm in the same paper by Bunck ** add gsl_vector_axpby() ** add un-pivoted LDLT decomposition and its banded variant (gsl_linalg_ldlt_* and gsl_linalg_ldlt_band_*) ** add binary search tree module (gsl_bst); based on GNU libavl ** remove -u flag to gsl-histogram ** updated spmatrix module - added routines and data structures for all types (float,uint,char,...) - added gsl_spmatrix_scale_columns() and gsl_spmatrix_scale_rows() - added gsl_spmatrix_add_to_dense() - more efficient reallocation of COO/triplet matrices (no longer rebuilds binary tree) - enhanced test suite - added gsl_spmatrix_min_index() ** add routines for banded Cholesky decomposition (gsl_linalg_cholesky_band_*) ** documented gsl_linalg_LQ routines and added gsl_linalg_LQ_lssolve()

```
It seems that the ReLAPACK authors were a bit pessimistic about the
possibility of a Level 3 BLAS recursive QR algorithm, since back in
2000, Elmroth and Gustavson published some work on exactly this. Their
algorithm tends to work best for "tall skinny" matrices with M >> N,
since the number of flops grows as O(N^3).
One of the LAPACK authors is currently doing research on this algorithm,
and has kindly provided GSL with GPL'd code to implement the
Elmroth/Gustavson algorithm, including the decomposition, Q^T b
calculation, and calculation of the full Q. All of these operations
significantly outperform the current Level 2 implementation for various
matrix sizes I have tried. Everything is already on the git. Due to the
nature of the new algorithm, I needed to create a new interface, which I
have suffixed with _r (i.e. gsl_linalg_QR_decomp_r).
So GSL now has "state of the art" algorithms for Cholesky, LU and QR.
These are exciting times :)
There are other parts of the library which use QR decompositions which
will likely benefit from this new algorithm, though I have not yet
converted them over.
Over the years, there have been discussions about whether we should
create GSL interfaces for LAPACK routines. I think these new
developments have reduced the need for that, though of course there are
many other areas where LAPACK is far superior (i.e. SVD, eigensystems,
COD).
Enjoy,
Patrick
On 6/8/19 2:45 PM, Patrick Alken wrote:
> The LU decomposition in GSL (both real and complex) is now based on a
> recursive Level 3 BLAS algorithm. The performance improvement is quite
> dramatic when using an optimized multi-threaded BLAS library like ATLAS.
> I'd be interested in hearing feedback from anyone who uses Cholesky/LU
> factorizations in their work. GSL may out-perform LAPACK in these areas
> now, and the recursive algorithms are surprisingly simple to implement
> and fit quite nicely with GSL's codebase.
>
> Enjoy,
> Patrick
>
> On 5/30/19 9:06 AM, Patrick Alken wrote:
>> Hi all,
>>
>>
>> I have recently learned of a project called ReLAPACK
>> (https://github.com/HPAC/ReLAPACK, paper here:
>> https://arxiv.org/abs/1602.06763) which implements a number of LAPACK
>> algorithms (such as LU, Cholesky, Sylvester equations) using recursive
>> methods which can use Level 3 BLAS calls. The paper shows that most of
>> these algorithms out-perform the block Level 3 algorithms in LAPACK. The
>> main advantage is that LAPACK block algorithms require fixing the block
>> size ahead of time, which may not be optimal for a given architecture,
>> while the recursive methods don't require a block size parameter.
>>
>> The recursive methods do however require a "base case" - i.e. at what
>> size matrix should it switch to the Level 2 BLAS based algorithms.
>> ReLAPACK fixes this currently at N=24.
>>
>> Anyway, the recursive Cholesky variant is quite straightforward to
>> implement, and I have already coded it for GSL (both the decomposition
>> and inversion). I did some tests for N=10,000 with ATLAS BLAS and found
>> that it runs faster than DPOTRF from LAPACK. This fast Cholesky
>> decomposition will improve the performance also for the generalized
>> symmetric definite eigensolvers, and the least squares modules (linear
>> and nonlinear).
>>
>> So GSL now has a competitive Cholesky solver, which I think should make
>> many GSL users happy :)
>>
>> Work is currently underway to implement the recursive pivoted LU
>> decomposition in GSL.
>>
>> Unfortunately the ReLAPACK authors state that the QR algorithm is not
>> amenable to recursive methods, so the block QR seems to still be the
>> best choice. It would be nice to implement this for GSL, in case any
>> volunteers are looking for a project ;)
>>
>> Patrick
>>
>>
```

```
The LU decomposition in GSL (both real and complex) is now based on a
recursive Level 3 BLAS algorithm. The performance improvement is quite
dramatic when using an optimized multi-threaded BLAS library like ATLAS.
I'd be interested in hearing feedback from anyone who uses Cholesky/LU
factorizations in their work. GSL may out-perform LAPACK in these areas
now, and the recursive algorithms are surprisingly simple to implement
and fit quite nicely with GSL's codebase.
Enjoy,
Patrick
On 5/30/19 9:06 AM, Patrick Alken wrote:
> Hi all,
>
>
> I have recently learned of a project called ReLAPACK
> (https://github.com/HPAC/ReLAPACK, paper here:
> https://arxiv.org/abs/1602.06763) which implements a number of LAPACK
> algorithms (such as LU, Cholesky, Sylvester equations) using recursive
> methods which can use Level 3 BLAS calls. The paper shows that most of
> these algorithms out-perform the block Level 3 algorithms in LAPACK. The
> main advantage is that LAPACK block algorithms require fixing the block
> size ahead of time, which may not be optimal for a given architecture,
> while the recursive methods don't require a block size parameter.
>
> The recursive methods do however require a "base case" - i.e. at what
> size matrix should it switch to the Level 2 BLAS based algorithms.
> ReLAPACK fixes this currently at N=24.
>
> Anyway, the recursive Cholesky variant is quite straightforward to
> implement, and I have already coded it for GSL (both the decomposition
> and inversion). I did some tests for N=10,000 with ATLAS BLAS and found
> that it runs faster than DPOTRF from LAPACK. This fast Cholesky
> decomposition will improve the performance also for the generalized
> symmetric definite eigensolvers, and the least squares modules (linear
> and nonlinear).
>
> So GSL now has a competitive Cholesky solver, which I think should make
> many GSL users happy :)
>
> Work is currently underway to implement the recursive pivoted LU
> decomposition in GSL.
>
> Unfortunately the ReLAPACK authors state that the QR algorithm is not
> amenable to recursive methods, so the block QR seems to still be the
> best choice. It would be nice to implement this for GSL, in case any
> volunteers are looking for a project ;)
>
> Patrick
>
>
```

Hi all, I have recently learned of a project called ReLAPACK (https://github.com/HPAC/ReLAPACK, paper here: https://arxiv.org/abs/1602.06763) which implements a number of LAPACK algorithms (such as LU, Cholesky, Sylvester equations) using recursive methods which can use Level 3 BLAS calls. The paper shows that most of these algorithms out-perform the block Level 3 algorithms in LAPACK. The main advantage is that LAPACK block algorithms require fixing the block size ahead of time, which may not be optimal for a given architecture, while the recursive methods don't require a block size parameter. The recursive methods do however require a "base case" - i.e. at what size matrix should it switch to the Level 2 BLAS based algorithms. ReLAPACK fixes this currently at N=24. Anyway, the recursive Cholesky variant is quite straightforward to implement, and I have already coded it for GSL (both the decomposition and inversion). I did some tests for N=10,000 with ATLAS BLAS and found that it runs faster than DPOTRF from LAPACK. This fast Cholesky decomposition will improve the performance also for the generalized symmetric definite eigensolvers, and the least squares modules (linear and nonlinear). So GSL now has a competitive Cholesky solver, which I think should make many GSL users happy :) Work is currently underway to implement the recursive pivoted LU decomposition in GSL. Unfortunately the ReLAPACK authors state that the QR algorithm is not amenable to recursive methods, so the block QR seems to still be the best choice. It would be nice to implement this for GSL, in case any volunteers are looking for a project ;) Patrick

```
Thanks Max, this is fine. I will take a look at your patch as soon as I can.
On 10/19/2018 05:10 AM, Max Bruce wrote:
> Hey guys,
>
> I'm new to contributing to GNU projects, but... I'm guessing I send
> commits through here? Would appreciate some sort of note on the
> procedure on the website
>
> I noticed that your matrix multiplication code had bad cache
> performance due to a misordering of a loop. In a replicated version of
> my change, I saw about 20% performance gains on my AMD FX CPU.
>
> Do let me know if this is not the correct contribution procedure.
>
> -Max
```

[-- Attachment #1: Type: text/plain, Size: 437 bytes --] Hey guys, I'm new to contributing to GNU projects, but... I'm guessing I send commits through here? Would appreciate some sort of note on the procedure on the website I noticed that your matrix multiplication code had bad cache performance due to a misordering of a loop. In a replicated version of my change, I saw about 20% performance gains on my AMD FX CPU. Do let me know if this is not the correct contribution procedure. -Max [-- Attachment #2: 0001-Reduce-cache-misses-for-source_gemm_r.patch --] [-- Type: text/x-patch, Size: 1622 bytes --] From 0345eaf2eb48997fa3d00fae2b37cf416d3713d4 Mon Sep 17 00:00:00 2001 From: JavaProphet <max.bruce12@gmail.com> Date: Thu, 18 Oct 2018 20:00:47 -0700 Subject: [PATCH] Reduce cache misses for source_gemm_r --- cblas/source_gemm_r.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cblas/source_gemm_r.h b/cblas/source_gemm_r.h index a008d22..7c9848e 100644 --- a/cblas/source_gemm_r.h +++ b/cblas/source_gemm_r.h @@ -71,8 +71,8 @@ /* form C := alpha*A*B + C */ - for (k = 0; k < K; k++) { - for (i = 0; i < n1; i++) { + for (i = 0; i < n1; i++) { + for (k = 0; k < K; k++) { const BASE temp = alpha * F[ldf * i + k]; if (temp != 0.0) { for (j = 0; j < n2; j++) { @@ -86,8 +86,8 @@ /* form C := alpha*A*B' + C */ + for (j = 0; j < n2; j++) { for (i = 0; i < n1; i++) { - for (j = 0; j < n2; j++) { BASE temp = 0.0; for (k = 0; k < K; k++) { temp += F[ldf * i + k] * G[ldg * j + k]; @@ -98,8 +98,8 @@ } else if (TransF == CblasTrans && TransG == CblasNoTrans) { + for (i = 0; i < n1; i++) { for (k = 0; k < K; k++) { - for (i = 0; i < n1; i++) { const BASE temp = alpha * F[ldf * k + i]; if (temp != 0.0) { for (j = 0; j < n2; j++) { @@ -111,8 +111,8 @@ } else if (TransF == CblasTrans && TransG == CblasTrans) { + for (j = 0; j < n2; j++) { for (i = 0; i < n1; i++) { - for (j = 0; j < n2; j++) { BASE temp = 0.0; for (k = 0; k < K; k++) { temp += F[ldf * k + i] * G[ldg * j + k]; -- 2.7.4

Moving this over to gsl-discuss since its not a bug. I would like to expand support for sparse matrices also. Ideally I would like to see GSL support the proposed Sparse BLAS standard (https://math.nist.gov/spblas/) which would likely address the points you raise below. I had some preliminary discussions a few months back with the maintainer of librsb (a sparse matrix library which fully implements the sparse BLAS standard, http://librsb.sourceforge.net/). In principle we might be able to port a lot of that code since it is a LGPL library. However the main issue is time. I am currently the only active GSL developer and have quite limited time these days. I would like to see more people work on these things and contribute to GSL, but I see few people volunteer. If you can write good code and know about sparse matrices, please consider working on these issues yourself and contributing a patch. Otherwise it will likely take me a long time to get to this :). But this is a relatively high priority item for me since I work with sparse matrices frequently in my own work. Thanks, Patrick On 07/12/2018 02:52 PM, David Cortes wrote: > The function for matrix multiplication for sparse matrices > (gsl_spblas_dgemm) currently only works when both inputs are in column- > compressed format. It would be straightforward to expand it to cover > also row-compressed matrices (without transposing them). > > As well, the spmatrix module supports convertion of > coordinates/triplets formats to row- and column-compressed, but it > doesn't support convertion from a compressed format to > coordinates/triplets. > > This makes it also problematic to perform basic algebra on matrices > which might later get multiplied. > >

Testing that the list is working

```
Hi Patrick,
Thank you for your suggestions.
I'll proceed following your advice.
Tito Sacchi
2018-06-06 4:33 GMT+02:00 Patrick Alken <alken@colorado.edu>:
> Hello,
>
> Thanks for some more details about what you want to do. It sounds from
> your description that this would be a substantial amount of code to be
> contributed to GSL (as opposed to one or two supporting functions, etc)
> - perhaps even a brand new module with numerous functions under it.
>
> First note that GSL attempts to follow the GNU coding standards
> (https://www.gnu.org/prep/standards/standards.html) as closely as
> possible, to achieve a uniform look and feel to the code throughout the
> library. Stability and clean interoperability is also a top priority for
> GSL, so adding a large chunk of new code will undoubtedly come with bugs
> and potential issues with interfacing with the rest of GSL. It is
> important that the design of your new module is well planned and thought
> out prior to adding it into the main GSL source tree, in order to
> achieve the simplest and cleanest API interfaces, the best
> implementation of the various algorithms you plan to use, etc.
>
> I recommend building your new module as a library extension, at least
> initially. This will give myself and others the chance to review your
> overall design, quality of the source code, etc, and make suggestions
> for improvement before it is folded into the main library. There will
> undoubtedly be multiple iterations of the code design before it is ready
> to be put in GSL.
>
> As an example, I myself have added a new module recently to GSL called
> gsl_movstat (moving window statistics). Prior to this, I had developed
> this as an external library more than 6 months ago, and did a complete
> redesign of that library twice in the last 6 months, before I knew it
> was ready to be put into GSL. Even after I put it into GSL, I spent
> several months writing tests, documentation, and tweaking the API calls
> to try to achieve the best results.
>
> None of this is meant to be discouraging. I think this has the potential
> to be a useful contribution to GSL. Its up to you now to do the work :)
>
> Patrick
>
> On 06/02/2018 01:26 AM, Tito Sacchi wrote:
>> Hello,
>>
>> I understand your doubts about the inclusion of new features into GSL.
>> I think that the combinatoric algorithms related to integer partitions are of
>> general interest and useful for a wide range of subjects.
>> The fact that many software companies have implemented packages
>> (e.g. Wolfram's Combinatorica [1], Maplesoft's Iterator [2]) for these
>> algorithms
>> for their own programs proves the importance and the general-purpose property.
>>
>> Among the most common applications:
>> - Young tableaux are useful for solving many basic combinatorial problems.
>> For example, the answer to the question "How many ways are there to arrange
>> a group of 25 students into a 5x5 grid such that in every row and every column
>> their heights are in incresing order (each row/column is independent
>> from each other)?"
>> is greater than 700M, and can be efficiently calculated using the
>> hook-length formula [3]:
>> it corresponds to the number of standard Young tableaux [4] of shape
>> [5, 5, 5, 5, 5].
>> - Also, they have applications in other fields of mathematics and in
>> physics. By means of
>> the Schur-Weyl duality [5] applied to the joint action of the
>> symmetric group S_k and the
>> general linear group GL(n) of invertible n x n matrices on tensor
>> spaces, using both the
>> hook-lenght formula [3] and the hook-content formula one can obtain
>> the dimensions of
>> the irreducible representations along with their multiplicities of
>> S_k and GL(n). This has
>> many applications in group representation theory, quantum
>> information theory, quantum
>> metrology, and particle physics. The implementation of this wouldn’t
>> even require
>> (representation) group theory support in the library.
>>
>> For more information see the Wikipedia pages below.
>>
>> [1] http://reference.wolfram.com/language/Combinatorica/guide/CombinatoricaPackage.html
>> [2] https://www.maplesoft.com/support/help/maple/view.aspx?path=Iterator
>> [3] https://en.wikipedia.org/wiki/Hook_length_formula
>> [4] https://en.wikipedia.org/wiki/Young_tableau
>> [5] https://en.wikipedia.org/wiki/Schur%E2%80%93Weyl_duality
>>
>>
>> 2018-05-31 21:16 GMT+02:00 Patrick Alken <alken@colorado.edu>:
>>> Hello,
>>>
>>> I certainly encourage more people working on GSL! Though keep in mind GSL
>>> aims to be a general-purpose scientific computing library. I personally
>>> don't work in combinatorics, so its difficult for me to gauge how many
>>> people would benefit / use these new algorithms you propose. If indeed a
>>> large number of users would like to see these algorithms in GSL, then
>>> certainly I would like to add them. However if only a small number of
>>> specialists would be interested, then I would say this work should be made
>>> into an extension library, which is as you say a self-contained external
>>> library which may or may not rely on GSL itself.
>>>
>>> Perhaps as a first step you could give some examples of what kinds of
>>> problems people can solve with these algorithms you are planning to code?
>>>
>>> Patrick
>>>
>>>
>>> On 05/31/2018 01:01 PM, Tito Sacchi wrote:
>>>> Greetings,
>>>>
>>>> I’d like to start working on some code on integer partitions,
>>>> combinatorics, and related algorithms
>>>> (Young tableaux, hook lengths...) in a new module that I’d call
>>>> “intpart” (or “intparts”, tell me).
>>>> I have already read the GSL Homepage which says that “any new
>>>> functionality is encouraged as
>>>> packages”, but such module isn’t very specific, and creating a package
>>>> would signify creating a totally
>>>> different library which probably wouldn’t even use any GSL function
>>>> (could we call it an extension?);
>>>> then we’ll end up with another C library which probably won’t get
>>>> integrated into GSL, so I thought
>>>> you might be interested in including it directly into the main library
>>>> (obviously after testing ecc.).
>>>> Just let me know if you prefer that I work on the anonymous clone of
>>>> the Savannah repo, or that I
>>>> start a separate project, maybe on GitHub.
>>>>
>>>> Yours sincerely,
>>>> Tito Sacchi
>>>
>>>
>
>
```