Skip to content
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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Kostas-Pallikaris
Copy link

Form Decomposition and Interior Product via String Manipulation

Form Decomposition and Interior Product via String Manipulation
@duetosymmetry
Copy link
Member

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.

@duetosymmetry
Copy link
Member

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.

@Kostas-Pallikaris
Copy link
Author

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?

@wtbgagoa
Copy link
Member

wtbgagoa commented Apr 3, 2019

I have a couple of comments:

  • I agree with @duetosymmetry that the ExtractComponents functionality is useful but I believe that the name should be changed in order to match similar functionality that already exists in other xAct packages. For example SeparateBasis in xCoba or SeparateSoldering form in Spinors perform similar tasks although in a different context (look at the on-line help of these functions). Therefore I would suggest renaming ExtractComponents to SeparateCoframe and adopt for it a syntax modeled on SeparateBasis
?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.
  • It is clear that SeparateCoframe requires that a new tensor be created. We faced a similar situation
    in Spinors when programming SeparateSolderingForm. In that case we prepended a mark (the spinor mark) to the symbol used for the original spinor. Something similar could be done here. Instead of using TensorOf[pform][-a,-b] I would suggest Markpform[-a,-b] where Mark is a symbol that can be chosen by the user by means of a global variable $FormTensorMark=Mark.

Kostas-Pallikaris and others added 5 commits April 5, 2019 05:31
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.
@Kostas-Pallikaris
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants