I needed to extend the ctransformlist to include the new ct_coords so the derivitives of the new equations were done correctly. The list is now the same as used in the ct_coordsys ( equations_list).
Thank you. Thought I'd let you know, the patch is not forgotten; working on incorporating it, I am just insane busy with other things, too, and juggling time. But it will be in the next version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see many coordinate transforms are new coordinates in terms of old coordinates. When there is not a possible way to get the inverse equations of old coordinates in terms of new coordinates, the current ctransformlist will not work.
I added an option parameter at the end like this newlg: ctransformlist(lg,list,inverse). The list of equations are new coordinates in terms of old. It calculates the transform for the new to old and then does an invert of the transform and used it without coordinate substitution. The same was done for the ctransformfrilist(fri,list,inverse).
I uploaded the new ctensorpath.mac file plus an example transformation file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found out I need to do no substitution when restoring back to original metric from the inverse metric. This in done with the option nosub instead of inverse.
I think there is a misunderstanding of what the tensor fri should look like. Here are some screen clips of Macsyma help, I have running in windows XP from copyright 1999.
Yes, I am aware of this patch and already implemented some of it. The rest, I am still contemplating. MACSYMA's implementation wasn't perfect so I don't necessarily believe that we need to follow it slavishly, therefore I am still hesitant about some of the suggestions here. Thank you very much for your hard work, though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand about the other changes, but the last comment was about the using lg() function in the lowering of the one index of Einstein tensor to get lein. If cframe_flag is true the lfg should be used and not lg. This error was also mentioned in the Physics Forums. some time ago. example is this thread. https://www.physicsforums.com/threads/brs-using-maxima-for-gtr-computations.378991/#post-2584071
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to assure you that it's not sloppiness on my part. I have
had some reservations concerning your patch, and also related fixes that
are "in the works", but I see no reason to be hasty, and I'd rather make
sure that the math is robust before messing up things. There will be
incremental fixes to come to ctensor, with apologies for being slow, as
I have to manage priorities.
Viktor
On 10/18/2023 2:48 AM, Richard Gobeli wrote:
This patch had nothing to do with the invert function plus Viktor only
so far fixed only some rarely used metrics.
Status: open Group: Created: Fri Jul 17, 2020 11:18 PM UTC by Richard Gobeli Last Updated: Wed Oct 18, 2023 05:51 AM UTC Owner: Viktor Toth Attachments:
Here are cframe examples and no frame examples using WxMaxima
Thank you for this submission. Please allow me to evaluate before accepting.
I see my comment has a misspelling. It should read like below:
Thanks for checking.
I needed to extend the ctransformlist to include the new ct_coords so the derivitives of the new equations were done correctly. The list is now the same as used in the ct_coordsys ( equations_list).
Last edit: Richard Gobeli 2020-08-01
I corrected your contragrade fix and added a coframe transform function ctransformfrilist. I added and not corrected.
Last edit: Richard Gobeli 2020-09-25
Thank you. Thought I'd let you know, the patch is not forgotten; working on incorporating it, I am just insane busy with other things, too, and juggling time. But it will be in the next version.
Here is a demonstration of the transforms.
Coordinate systems were varified with this comparison to original transform equations using ctransfomlist.
I see many coordinate transforms are new coordinates in terms of old coordinates. When there is not a possible way to get the inverse equations of old coordinates in terms of new coordinates, the current ctransformlist will not work.
I added an option parameter at the end like this newlg: ctransformlist(lg,list,inverse). The list of equations are new coordinates in terms of old. It calculates the transform for the new to old and then does an invert of the transform and used it without coordinate substitution. The same was done for the ctransformfrilist(fri,list,inverse).
I uploaded the new ctensorpath.mac file plus an example transformation file.
I had a spelling mistake in names in both files.
I found out I need to do no substitution when restoring back to original metric from the inverse metric. This in done with the option nosub instead of inverse.
I think there is a misunderstanding of what the tensor fri should look like. Here are some screen clips of Macsyma help, I have running in windows XP from copyright 1999.
shouldn't the leinstein function use the _lg() function in the following lines:
lein[i,j]:if diagmetric then ein[i,j]+lg[i,j]
else sum(ein[i,k%]*lg[k%,j].k%,1,dim),
This is so the lfg is used when the cframe_flag is true and lg is used when cframe_flag is false.
Did you see this change or do I need to put this also as a bug report?
Yes, I am aware of this patch and already implemented some of it. The rest, I am still contemplating. MACSYMA's implementation wasn't perfect so I don't necessarily believe that we need to follow it slavishly, therefore I am still hesitant about some of the suggestions here. Thank you very much for your hard work, though.
I understand about the other changes, but the last comment was about the using lg() function in the lowering of the one index of Einstein tensor to get lein. If cframe_flag is true the lfg should be used and not lg. This error was also mentioned in the Physics Forums. some time ago. example is this thread. https://www.physicsforums.com/threads/brs-using-maxima-for-gtr-computations.378991/#post-2584071
Got a cryptic report about this patch for wxMaxima that seems to indicate that it might cause regressions in maxima: https://github.com/wxMaxima-developers/wxmaxima/issues/1823
This patch had nothing to do with the invert function plus Viktor only so far fixed only some rarely used metrics.
Dear Richard:
Just wanted to assure you that it's not sloppiness on my part. I have
had some reservations concerning your patch, and also related fixes that
are "in the works", but I see no reason to be hasty, and I'd rather make
sure that the math is robust before messing up things. There will be
incremental fixes to come to ctensor, with apologies for being slow, as
I have to manage priorities.
Viktor
On 10/18/2023 2:48 AM, Richard Gobeli wrote:
Related
Patches: #96