-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the status of symbolic matrices? #16
Comments
Hi, There are two ways to support symbolic matrices (or complex ones etc) the symbolic wrapper could also wrap an arbitrary core.matrix implementation that allows for Object elements and this way for the cost of another indirection all existing core.matrix implementation can be leveraged. 2.) the symbolic matrices repository tested another aproach: I don't have enough time currently to give serious implementing symbolic matrices a try myself, but I would gladly support you (or anyone willing to do this) with guidance on using expresso / fixing bugs that pop up :) I haven't looked in detail at the recent try to support complex numbers in core.matrix,but it looks promising. and the discussion on the clojure numerics mailing list |
I see, thanks for the detailed overview and the links. As far as I can tell the thread didn't really conclude with a definite answer, but at least it mentioned some things to consider. The implementation for complex matrices is a good reference. I find it interesting that in the thread you linked @mikera seems to argue in favor of your approach 2., but implemented complex matrices as a separate class anyway. I can see why this approach is compelling in this case though, since splitting the matrices into real and complex part allows reusing all other implementations. I would very much like to try the second direction you mentioned, since I also believe that it is the most natural way to do it and other systems seem to fare quite well with it, e.g. sage's symbolic rings. I would define protocols for rings or fields, and then define an abstract matrix class parameterized by its underlying ring. I hope that is what you had in mind :) This might also provide an elegant (albeit partial and potentially slow) solution for the AB vs. BA problem: You could just define one function per pair that exhibits the underlying ring of A as a subring of the one underlying B and vice versa, very much limiting duplication. |
FWIW I think that different use cases require different implementations. There is a big tradeoff between making things very generic through abstraction and making them efficient. https://github.com/mikera/core.matrix.complex is meant to be fairly lightweight and fast. In order to do that, the implementation is deliberately specialised to complex values only. I'd fully support experiments to make more generic implementations, I just think that these would have quite different design goals. They would probably be of more interest in academic context, whereas the more specialised implementations are likely to appeal to industry practitioners. The nice thing about core.matrix is that these implementations can inter-operate.... so it isn't really an either/or decision, we can have both. |
Sure, there is always a tradeoff, even with macros. Like I said, I see why this particular implementation is very appealing. If the parameterized arrays work as expected, I can probably provide the other end of the spectrum pretty easily. |
Ok, so I played around with it a bit, but I ran into a problem that I could use your help with: When I implement the arrays on top of the most general object container arrays, having something like (* 5 a) in them messes up the built in dimensionality checkers. Do I need to put every entry in a wrapper type, or is there a smarter solution? I like how it is handled in core.matrix.complex, where the explicit element type is only constructed when needed, as for example in the get-FOO-d functions. |
Hmm, I think that is a current limitation of core.matrix because it regads everything seqable as an array and not a scalar. Is this correct @mikera ? If this is the case, then I see no better solution as using a wrapper type. using the wrapper type one still could extract the underlying expression from the wrapper type in the get-FOO-d functions. |
Yeah, we probably shouldn't interpret arbitrary sequences as arrays. I've been playing around with this a bit, it gets tricky because of the number of permutations. But I think we will revert to considering plain sequences as scalar values (except in a few limited cases like array construction, perhaps...) We need to consider vectors as arrays though - we have to make them count as arrays or else the :persistent-vector implementation can't work. My suggested workaround is that if you want to put sequences / vectors as scalar elements then you should use an implementation that explicitly stores the array shape (e.g. NDArray). Then you avoid any ambiguity. |
Hm, I would like to keep the implementation as general as possible, but I think using NDArray and specifying the dimensions is the most elegant way to do it here (Apart from core.matrix dropping the support for sequences as arrays of course). Since my approach is supposed to support arbitrary rings, and since construct-matrix should be implemented independently of the structure of the underlying ring, it would feel pretty weird to have to do something like (matrix [[(Fraction. 1/2) (Fraction. 0/1)]...]) Thanks for the suggestions, I'll try using NDArray now. |
I saw you have a dedicated repository, but since its documentation still is a little sparse, I am not sure if that's still the preferred way or even how to add the implementation? I would be willing to help with the integration & documentation if there is something I can do.
The text was updated successfully, but these errors were encountered: