- Numeric - Haskell.org

Announcement: Fast linear programming with highs-lp
by Henning Thielemann 03 Jan '24

03 Jan '24

Eventually I have also written a basic wrapper to the relatively new linear programming solver HiGHS based on the comfort-array types: https://hackage.haskell.org/package/highs-lp Warm start of the solver is supported by a monadic interface. The QuickCheck tests in coinor-clp and highs-lp already revealed several issues, that are now fixed in the latest commits, that is, COIN-OR/Clp:master and HiGHS:latest. Here is a Nix file for building the currently latest HiGHS commit: https://hub.darcs.net/thielema/highs-lp/browse/highs.nix For building master/HEAD of COIN-OR/Clp, you may find these Nix files useful: https://hub.darcs.net/thielema/coinor-clp/browse/nix

1 0

Announcement: ods2csv - extract data from ODS as written by LibreOffice Calc
by Henning Thielemann 17 Sep '23

17 Sep '23

I released ods2csv: https://hackage.haskell.org/package/ods2csv It extracts plain data from ODS/FODS documents without the need to install or run libreoffice, since it is based on a simple XML scanner. With "libreoffice --headless" or "unoconv" I had endless hassle to cope with running instances of LibreOffice and selecting a certain table. In contrast to that, ods2csv is lightweight and fast.

1 0

Announcement: Fast linear programming with comfort-glpk and coinor-clp
by Henning Thielemann 14 May '23

14 May '23

I happily released two other numeric packages based on the comfort-array types. These are bindings to fast numeric linear programming solvers: https://hackage.haskell.org/package/comfort-glpk https://hackage.haskell.org/package/coinor-clp The first one is (another) binding to GLPK and the second one is a binding to COIN-OR/CLP. I guess this is the first Haskell binding to COIN-OR/CLP, at all. I found that the COIN-OR solver is not as simply structured as GLPK and the examples miss the simple use cases, but its performance is much better than that of GLPK and its interior point solver (Method.initialBarrierSolve) just works, in contrast to the one of GLPK. Warm start of solvers is supported by according monadic interfaces. Both packages use the same types to describe linear programming problems, thus you can describe your problem once and then simply choose the appropriate solver. The types are exported by the package linear-programming. The flexible array shapes provided by comfort-array help a lot to structure the problem variables. This saves you from the need to manually work with integer indices. You can concatenate array shapes with (::+) and establish Cartesian products with (,) and define array shapes that are compatible with nested tuples (e.g. Shape.NestedTuple ((X,X),(X,X,X))) or define arrays with indices of any Enum type (Shape.Enumeration).

1 0

Announcement: Fast Fourier transform with comfort-fftw
by Henning Thielemann 11 Aug '21

11 Aug '21

I have released: https://hackage.haskell.org/package/fftw-ffi https://hackage.haskell.org/package/comfort-fftw This is an alternative to the 'fft' package (based on 'carray' and 'ix-shapable'). The package comfort-fftw is based on comfort-array and uses Cyclic and Half Spectrum shapes. The Cyclic shape allows you to access the (n-1)-th element also by index (-1). This reflects the cyclic interpretation of data implied by the discrete Fourier transform. The Half Spectrum shape greatly simplifies working with the spectrum of real data, both of even and odd length, and reduces the danger of mistakes. The bindings use distinct array shapes for the four kinds of both cosine and sine transformation and thus ensure, that you use the right one for back transformation. Two examples may demonstrate its usage: https://hackage.haskell.org/package/align-audio Find relative displacement of two recordings of the same music. https://hackage.haskell.org/package/sound-collage Assemble a mosaic of sound snippets according to a target music recording.

1 0

Announcement: lapack-0.4
by Henning Thielemann 10 Aug '21

10 Aug '21

I'm happy to release lapack-0.4, a new version of the high-level bindings to LAPACK (i.e. efficient numeric linear algebra). News: * Even more unified Matrix type Allows for a generic 'transpose' function. * Support for unpacked triangular, symmetric and Hermitian matrices. * Two distinct types of Square matrices: One with equal and one with distinct height and width shape types. * Hermitian: added definiteness information to the type * Matrix functions sqrt, exp, log also for special matrix types (triangular, unit triangular, Symmetric, Hermitian) * Infix operator fun You may write a#^T for transpose and a#^Inv for inverse etc. Certainly not for serious use but I found the idea funny.

2 1

Fwd: HMatrix priorities
by dominic＠steinitz.org 10 Jul '20

10 Jul '20

Hi Huw, Thanks very much for the questions and working on hmatrix. Apologies for not having more informative answers. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > On 8 Jul 2020, at 08:18, Huw Campbell <huw.campbell(a)gmail.com> wrote: > > Hi all, > > I've put a bit of time into hmatrix over the past week. My main > priorities at the moment are fixing bugs, segfaults, memory leaks, and > other infelicities. But after that's done I'm planning on tackling > some broader API and design issues. > > I have a few questions: > > - Why are CSR and CSC 1 indexed? The early literature uses 0 indexing > AFAICS, and it means that Ben Gamari's libsvd wrapper has to do extra > leg work reindexing before calling its C code. I didn’t even know it did this. I don’t think the author (Alberto Ruiz) is subscribed to this list. We could try asking him directly. > - Why do we have our own mutable vector type? I would have thought the > version in > the vector package would be sufficient. My guess would be that when the code was written mutable vectors were not available in vector. > - Should we try to move more of the library towards the general matrix > `GMatrix`? At the moment there are not very many functions which > actually use it (and it has partial record labels), and one can't > project out back to any of the underlying matrix forms. I have no view on this other than to be careful about performance which reminds me: we should really do some performance measurements. > - Can we bring the test suites and benchmarks back into the libraries > proper? The test suite is currently lagging the major version, and on > master doesn't compile with GHC 8.6+ (I have a PR for that). Yes please. > - CI looks like it's only testing one version of GHC, do we have a > policy on how many versions we support? No policy but I guess we should aim for a few more versions. > - What are all of your priorities? Dominic has mentioned a few use cases around > sparse matrices people have been working on. Some time ago, I created hmatrix-sundials but gave it its own repo. The idea was to have an identical interface to ODE solving so that you could switch between SUNDIALS and GSL. Roman Cheplyaka has vastly improved hmatrix-sundials and it now uses suitesparse for sparse matrices. In terms of priorities, my own are focussed on solving PDEs so I really need sparse matrices. And SUNDIALS is really a lot better for differential equations than GSL. I really like the statically typed matrices (the rows and columns being typed by their size). Are you thinking just about the base package or the other packages like glpk? > We've also spoken about github etiquette. I agreed with Dominic that > branches and pull requests are probably the best approach at the > moment. I won't merge my own PRs without input from another maintainer > at this stage, so please do have a look. I am not totally convinced having a monorepo is the best way forward but I don’t feel strongly. > Regards, > Huw > _______________________________________________ > Numeric mailing list > Numeric(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/numeric

1 0

HMatrix priorities
by Huw Campbell 08 Jul '20

08 Jul '20

Hi all, I've put a bit of time into hmatrix over the past week. My main priorities at the moment are fixing bugs, segfaults, memory leaks, and other infelicities. But after that's done I'm planning on tackling some broader API and design issues. I have a few questions: - Why are CSR and CSC 1 indexed? The early literature uses 0 indexing AFAICS, and it means that Ben Gamari's libsvd wrapper has to do extra leg work reindexing before calling its C code. - Why do we have our own mutable vector type? I would have thought the version in the vector package would be sufficient. - Should we try to move more of the library towards the general matrix `GMatrix`? At the moment there are not very many functions which actually use it (and it has partial record labels), and one can't project out back to any of the underlying matrix forms. - Can we bring the test suites and benchmarks back into the libraries proper? The test suite is currently lagging the major version, and on master doesn't compile with GHC 8.6+ (I have a PR for that). - CI looks like it's only testing one version of GHC, do we have a policy on how many versions we support? - What are all of your priorities? Dominic has mentioned a few use cases around sparse matrices people have been working on. We've also spoken about github etiquette. I agreed with Dominic that branches and pull requests are probably the best approach at the moment. I won't merge my own PRs without input from another maintainer at this stage, so please do have a look. Regards, Huw

2 1

Re: [Numeric] HMatrix collaboration
by dominic＠steinitz.org 07 Jul '20

07 Jul '20

Hi Huw, You are right. I have given you access to the hmatrix repo. We don’t currently have any modus operandi for the organisation in which this repo lives. I assume that we will all create branches for review before merging? I’ve cc’d the somewhat unused mailing list. If that doesn’t work for e.g. Q&A then we can try something else. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > On 6 Jul 2020, at 08:09, Huw Campbell <huw.campbell(a)gmail.com> wrote: > > Hi Dominic, > > Thanks very much. I still can't seem to push to the hmatrix repository, I think the permissions are separate to the haskell-numerics organisation. > > Is there a mailing list or unofficial list of email addresses we can use for questions and change proposals? Some questions (like, why is CSR 1 indexed?) feel a bit strange for an issue tracker. > > Regards, > Huw > > On Sat, Jul 4, 2020 at 5:56 PM <dominic(a)steinitz.org <mailto:dominic@steinitz.org>> wrote: > Hi Huw > > Great 😁 > > I am just about to go out but some thoughts > > Roman Cheplyaka has updated hmatrix-sundials to use sparse matrices - I have an application for this solving some PDEs which I have yet to try. > > I think Henning Thielemann has also done some work on sparse matrices / bindings to BLAS / LAPACK. > > The collaborative effort to improve random number generation worked really well - hopefully we can repeat the experience in this important area. > > Dominic Steinitz > dominic(a)steinitz.org <mailto:dominic@steinitz.org> > http://idontgetoutmuch.org <http://idontgetoutmuch.org/> > Twitter: @idontgetoutmuch > >> On 4 Jul 2020, at 05:05, Huw Campbell <huw.campbell(a)gmail.com <mailto:huw.campbell@gmail.com>> wrote: >> >> Hi Dominic, >> >> I've been thinking about putting some more work into hmatrix for a few >> years now, ever since I used it effectively in my neural network >> library Grenade. >> >> I currently have a few PRs up to fix and speed up sparse matrix creation. >> >> I would like to really tighten up its benchmark and test suites (bring >> them into the packages themselves instead of hosting them in an >> external package; remove the poorly conceived `Testable` type class; >> using criterion a lot more; and possibly porting tests to hedgehog). >> >> Other items on the cards are using im2col to speed up convolutions (I >> have this working in Grenade already) and make them easier to use with >> user defined padding and stride. >> >> It's quite a bit to do, so I was wondering if I could become a collaborator? >> >> In terms of Haskell projects I maintain, the main open source one >> these days is optparse-applicative, which I've been incrementally >> improving over the past 5 years. >> >> Kind regards, >> Huw >

2 1

Talk on LAPACK bindings
by Henning Thielemann 13 Nov '19

13 Nov '19

Hi all, I have noticed that my Summer BOB talk on my new shiny LAPACK bindings is now online: https://bobkonf.de/2019-summer/thielemann.html Best, Henning

1 0

Getting blas-ffi to build under nix
by dominic＠steinitz.org 28 Aug '19

28 Aug '19

I thought I would broaden out the discussion Henning and I have been having. I have managed to get http://hackage.haskell.org/package/blas-ffi <http://hackage.haskell.org/package/blas-ffi> to build under nix. Ideally we would like cabal2nix to do this automatically for us. We can do this if We use openblas rather than blas. Replace `PkgConfig-Depends: blas` with `PkgConfig-Depends: lapack (as the lapack derivation in nix generates a blas.pc) in the cabal file. Fix nix to generate .pc files for blas - I don’t know the consequences of doing this but I can’t see any downside. Does anyone have any views on what might be the best approach? Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > Begin forwarded message: > > From: dominic(a)steinitz.org > Subject: Getting blas-ffi to build under nix > Date: 28 August 2019 at 13:31:45 BST > To: Henning Thielemann <lemming(a)henning-thielemann.de> > > Hi Henning, > > I think there are 3 options (in nix - they may not work elsewhere) > > Use openblas rather than blas > Replace `PkgConfig-Depends: blas` with `PkgConfig-Depends: lapack` > Fix nix to generate .pc files for blas (it does this for openblas and lapack, the latter also generates a blas.pc file > > I don’t have a strong preference but I think I’d go for using openblas. I can send a patch but of course it’s a 1 line change so maybe you could just do it yourself and release a new version to hackage? > > Dominic Steinitz > dominic(a)steinitz.org <mailto:dominic@steinitz.org> > http://idontgetoutmuch.org <http://idontgetoutmuch.org/> > Twitter: @idontgetoutmuch > > > >

2 2