Closed SamuelSchlesinger closed 7 years ago
This is a good idea! It definitely makes sense to factor out blas as a separate interface. What exactly do you mean by 'signature', by the way?
Signatures like in something like backpack: http://plv.mpi-sws.org/backpack/
I'm going to do this today, calling it "abstract-BLAS"
@SamuelSchlesinger Are you aware that backpack is not yet available in any released version of GHC?
Yeah, I was just talking about it as a design choice in general @cocreature even though it's probably not too relevant right now as I think you suggest.
Hi @SamuelSchlesinger, did you ever make progress on blas-as-a-library? i'm doing something else now and I wouldn't mind pulling it in as a standalone dependency :)
I didn't, no, but I found this bad larry: https://hackage.haskell.org/package/fpnla. I think the main problem with doing so is that you'd like to have BLAS as the old BLAS where you pass in pointers but you'd also want to include hmatrix type interfaces as well, so I kind of was at a loss of what to do here.
I've been having some major problems with space complexity when trying to write numerical code to rival things like C++ and Python and its starting to get totally frustrating, curious if you've been facing similar difficulties by any chance. I know you had some problems with tensor-ops which seemed to be space related, no?
Hey Justin! I'd love to isolate BLAS and use it as a standalone library, it's something that I think would be incredibly useful for many people doing projects like this, as I am right now approaching something similar to you and had the same thought of factoring out BLAS as you have.
One question I had for myself was whether it was better to factor it out as a signature or as a class, as you have. I feel signature ensures that performance won't take a hit, but class allows for more versatility I believe, as I'm not sure if you can instantiate signatures at multiple types in a single package.