You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to have a "J" matrix that works similar to uniform scaling. So if I have a matrix A=rand(4,4) for example, I can just write A*JMatrix for example, instead of having to explicitly define the JMatrix(4) size.
I can see two ways of doing this: one way is to just define a new empty type, say SymplecticS, define const S = SymplecticS() (I choose S because in accelerator physics we reserve J for the invariant action and call this matrix S) and then for all operations have it check the size of the other matrix, create the JMatrix and run the current JMatrix operation. This option is least invasive and easy, but redundant.
The other option is to rewrite JMatrix to instead have it not have size n as a field, and infer the size at time of an operation from the other matrix. This option is more invasive, and with my limited knowledge of this package may not be doable/preferred for certain reasons.
Would any of the above options be considered for a PR?
The text was updated successfully, but these errors were encountered:
That would be a bit different from the JMatrix type defined here, so in principle it would be a breaking change. (Though I'm not sure how widely used the skew-Cholesky factorization is in practice; probably not very much.)
(And if it is analogous to UniformScaling, it would also include a scale factor.)
I would like to have a "J" matrix that works similar to uniform scaling. So if I have a matrix
A=rand(4,4)
for example, I can just writeA*JMatrix
for example, instead of having to explicitly define theJMatrix(4)
size.I can see two ways of doing this: one way is to just define a new empty type, say
SymplecticS
, defineconst S = SymplecticS()
(I chooseS
because in accelerator physics we reserve J for the invariant action and call this matrix S) and then for all operations have it check the size of the other matrix, create theJMatrix
and run the currentJMatrix
operation. This option is least invasive and easy, but redundant.The other option is to rewrite
JMatrix
to instead have it not have sizen
as a field, and infer the size at time of an operation from the other matrix. This option is more invasive, and with my limited knowledge of this package may not be doable/preferred for certain reasons.Would any of the above options be considered for a PR?
The text was updated successfully, but these errors were encountered: