Comments (8)
No problem!
I've switched, for now, to interfacing directly with CHOLMOD--via hcholmod and some additions for sparse-linear-algebra.
But I think I'd rather work with a more complete sparse library. So maybe I'll circle back once you've settled on an interface via the "safe" wrapper.
Thanks for the work!
from eigen.
Hey, thanks for your interest in this library!
Yes - this (core) library makes it a point to avoid anything LGPL. However, I have thought about a separate library (named eigen-lgpl
?) that implements a lot of the LGPL stuff. If you'd like to take a stab at it, please go ahead!
from eigen.
Great! I'll probably start by just trying to get it working as a piece of the thing I'm working on but if it's straightforward enough, I'll roll the eigen parts out as a separate lib. And I'll try to adhere to your style, etc. when possible.
from eigen.
Thanks!
from eigen.
Okay. I'm trying to understand things and am deeply confused but that will probably get better.
My rough sense is that I need to have
- cbits/eigen-lgpl-sparse-la.cpp (with the typedefs and switches and c++ stubs for the FFI calls? More on this below)
- src/Eigen/Solver/SimplicalCholesky, with
- the
newtype
forSimplicalLLT
andSimplicalLDLT
and - class instances for
Solver
,DirectSolver
, andCode
with an implementation assigning ints to the solver/ordering combos. See below. - Perhaps an additional function to match the
vectorD
class method for returning the diagonal matrix D in the LDLt decompositions.
- Perhaps a
foreign import call...
forvectorD
in something like Eigen/LGPL/Internal.hsc
Some questions:
A. I need to add instances to those switch
staements in eigen-sparse-la.cpp. Is there some best way to just add my cases (in cbits/eigen-lgpl-sparse-la.cpp) and refer the rest back to the function in the original library? I don't quite see how to do this since all the solver infrastructure, including that switch statement, is in eigen and I'm not looking to duplicate anything, just add the simplical solver cases.
B. I'm not quite sure what name or args vectorD
ought to have in the in the Internal module. My best guess was
#api3 sparse_la_vectorD, "CSolverPtr -> Ptr (C a) -> CInt -> CInt -> IO String"
but only because I am wildly guessing that you handle vectors as Matrices with only one column or row and other functions returning a matrix seem to end in Ptr (C a) -> CInt -> Cint
C. Related to "B", I notice that the other functions returning decomposition components, like matrixL
, etc. are unimplemented. Can that be fixed? I need to get the underlying L in the LLt decomposition. Or at least the log of its determinant.
Any help would be much appreciated here!
from eigen.
I feel like this is going to need to be more of a partial fork than an add-on. Because the solvers work via that switch statement, I need to reroute them all to a new switch to pick up the new cases and that's true of many functions. Hopefully I can fork only SparseLA and Internal.
Is there some way to re-design how eigen dispatches to the underlying c++ which would make it easier to add bits like this? Maybe it's just as simple as adding hooks into the switch statements which an add-on lib could use to add cases? I'm not clear enough yet...
from eigen.
And I think this might be a little beyond me, at least without more help. This fork idea seems bad, since any API change at the eigen level will mean re-writing the whole thing. But I don't see how else to do it.
And I'm going to need to get the actual Cholesky factor out as well as the permutation matrix that analyze computes. But there aren't any examples of that I can follow since the factor out functions matrixL
, etc. are unimplemented and I see no examples which produce a dense vector (which is what the permutation matrix is).
Also, I need to be able to stack sparse matrices horizontally and vertically, something I don't see how to do in the c++ library or the haskell.
I'm sure all those things can be done. But having so much unknown makes it harder for me to guess how much work it might be to get to where it's useful for my particular problem.
If you could talk me through a bit of that, so I can see what needs to be done and what the right way to do it might be, that would help me decide if it makes sense to jump in.
from eigen.
I deeply apologise for taking so long to respond. This issue became active when I was predisposed, and then I never circled back. The current interface to the C++ is a pretty hacky, inherited blob of sinister lurking bugs. These bugs have been smashed out AFAIK, but like you say, the addition of more switch/case makes this marshalling's brittleness rear its ugly head. If you have a way to improve this situation, I would gladly take suggestions.
Furthermore, and this may affect your work on any of this, I've recently stumbled upon/played around with an interface to the statically verified/"safe" wrapper that this library provides that will significantly increase ergonomics. However, this will be a breaking change (This package doesn't follow PVP anyway, but still users might have a tough time migrating. The introduction of the first static interface was tough enough.)
Please reach out to me more on this issue and I will try hard to be more prompt. Sorry again.
from eigen.
Related Issues (20)
- incorporate internal changes from internal-refactor branch
- [Ported Issue] Why define IOSparseMatrix instead of MSparseMatrix? HOT 1
- [Ported Issue] Geometry wrappers are not written HOT 2
- [Ported Issue] Sparse Matrix Accession HOT 1
- [Ported Issue] Support Row Major
- [Ported Issue] Unsupported Modules
- Totality
- kronecker product
- Build issues HOT 9
- getCols and getRows HOT 4
- missing functions from refactor HOT 8
- Can Haskell bindings be updated to use Eigen 3.3.5 version ? HOT 4
- all functions should be SPECIALISED
- folds
- inlining
- move all refinements to Eigen.Refined
- Sparse matrix eigenvectors / eigenvalues HOT 1
- Sparse matrices whose size is not known at compile time HOT 1
- Compile time check for in-bounds access is wrong :( HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eigen.