-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add files via upload #2
base: master
Are you sure you want to change the base?
Add files via upload #2
Conversation
Form Decomposition and Interior Product via String Manipulation
I can see the ExtractComponents functionality being useful. Before considering this for merging, please rewrite to avoid any string manipulation. Instead use the structure of the expression itself, which is already an abstract syntax tree. |
We must also think about the structure of the objects that are being created. It is a type mismatch to have the same object with a different number of indices (i.e. pform[] and pform[-a,-b]) unless it is specifically intended to have a variable number of indices. I think it is preferable to have a head to associate a tensor with an index-free form, i.e. TensorOf[pform][-a,-b]. This should be discussed. I'm sure @wtbgagoa has some thoughts on this topic. |
I completely agree that string manipulation is bad programming. I will try to implement this in a better way close to the rest of the code (not really familiar with it, but I'll have a go). Moreover, the interior product extension to include indexed vector fields works, but is a terrible fix regarding programming integrity. Also, now I noticed for example that when the tensor components are automatically defined with ExtractComponents, I forgot to also force them to inherit the symmetry group of the form itself. Nevertheless, I will rewrite this and pull. Can you also pinpoint where the same object arises? |
I have a couple of comments:
?SeparateBasis
SeparateBasis[basis][expr, indices] expands indices of objects in expr into
products of Basis objects and the original objects, using contractions
of indices specified by basis. When basis
is AIndex or is not given, abstract indices are used. The list of indices
can be supplied in different ways, using IndicesOf[selectors], a list of
g-indices with head IndexList or a single g-index. See the
documentation for IndicesOf for a complete list of
possible selectors.
|
This is the m file for the SeparateCoframe command. Up to now, this only works for a single form. I avoided the easy solution which was to create new indices all the time. I used DefTensor because I had a bug with the PrintAs attribute when I tried this by setting the attributes (still trying to find why it didn't accept it). Possible issues: -Is it better to use DefTensor for the tensor components or simply fix the necessary attributes in ?Head ? -There seems to be a lack of validation for some things (this is irrelevant to the SeparateCoframe). It may be that my mathematica is For example, Times is allowed between forms, which makes no sense. Normal addition of forms of different degree is also another thing that does not throw an error. (Probably these are due to the fact that diff forms are using the DefTensor option??). Also, when the degree exceeds the the top-form deg, the expression does not vanish upon validation. I will try to collect those thing in an example.nb and commit. -Indeed, there is conglict right now if one defines forms without indices. For example in the Int code, the form without indices will be ignored by the intertior product. TO DO (Separate Coframe): -Rules for handling Wedge, Plus and Times input. Rules for ?constantQ input and input with Deg 0. -Put option WithRespectTo->{Coframe[mani],dx[mani]} -CTENSOR implementation for this? -Indeed, there is conflict right now if one defines forms without indices. For example in the Int code, the for without indices will be ignored by the intertior product.
Long time no see. Rewrote the code for ``ExtractComponents'' and named it FormsToTensors in the fashion of CurvatureFormToTensor etc. The expansion is with the convention I use, this can always be converted to the xAct convention. The idea with the Mark is really nice and can be easily implemented I think. For now, I am using GiveSymbol[Form,Tensor] and clearing/redefining the guy if it already exists.
Hi guys! Long time no see. I hope you are all fine. I have uploaded a new FormsToTensors code without any use of strings as in the old SeparateCoframe code. Have a look and let me know. The use of mark is a good idea for the new tensor, for the moment in the unlikely scenario that a tensor with the given name exists, I do a ClearAll and redefine appropriately. TODO: Expand Diff on 0-forms, include already defined cases like ConnectionForm, CurvatureForm etc. inside FormsToTensors. |
Form Decomposition and Interior Product via String Manipulation