I see Raymond has made a good simplification of the code. Thanks,
Here is the updated patch with the text field set to 26 and the ~26a is corrected.
I have a work file that when loading contrib_ode I get thses warnings. My work sheet uses N,Q,V, and X. I don't know, if the intenal variables will affect or be affected by the external variables. (%i405) load( "contrib_ode"); ; file: C:/maxima-current/share/maxima/branch_5_47_base_526_g08584e36f/share/contrib/diffequations/odelin.lisp ; in: DEFUN HYPERGEO21-XI-DENOM-FILTER ; (IGNORE MAXIMA::N) ; ; caught STYLE-WARNING: ; Declaring special variable N to be IGNORE ; file: C:/maxima-current/share/maxima/branch_5_47_base_526_g08584e36f/share/contrib/diffequations/odelin.lisp...
A nicer formated print directories like used in the WxMaxima Wxbuild_info
But one of the sign cases is not provided. It should ask is it zero, positive, negative, or can it be the general case of both positive or negative in different ranges. This is something to think about.
I found that I can stop the conversion of sqrt(x^2) to x by using the radexpand flag set to false. This then gets the right answer, but to simplify the answer the radcan does not use the radexpand flag. (%i1) radexpand:false; (%o1) false (%i2) eq1:%e^-(x/σ)^2; (%o2) %e^(-(x^2/σ^2)) (%i3) integrate(eq1,x,minf,inf); (%o3) sqrt(%pi)/sqrt(1/σ^2) --> radcan(%); (%o4) sqrt(%pi)*σ This should simplify to sqrt( %pi * σ^2) or sqrt(%pi) * abs(σ).
I found that I can stop the conversion of sqrt(x^2) to x by using the radexpand flag set to false. This then gets the right answer, but to simplify the answer the radcan does not use the radexpand flag. (%i1) radexpand:false; (%o1) false (%i2) eq1:%e^-(x/σ)^2; (%o2) %e^(-(x^2/σ^2)) (%i3) integrate(eq1,x,minf,inf); (%o3) sqrt(%pi)/sqrt(1/σ^2) --> radcan(%); (%o4) sqrt(%pi)*σ This should simplify to sqrt( %pi * σ^2).
I found that I can stop the conversion of sqrt(x^2) to x by using the radexpand flag set to false. This then gets the right answer, but to simplify the answer the radcan does not use the radexpand flag. (%i1) radexpand:false; (%o1) false (%i2) eq1:%e^-(x/σ)^2; (%o2) %e^(-(x^2/σ^2)) (%i3) integrate(eq1,x,minf,inf); (%o3) sqrt(%pi)/sqrt(1/σ^2) --> radcan(%); (%o4) sqrt(%pi)σ This should simplify to sqrt( %piσ^2).
(%i1) radexpand:false; (%o1) false (%i2) eq1:%e^-(x/σ)^2; (%o2) %e^(-(x^2/σ^2)) (%i3) integrate(eq1,x,minf,inf); (%o3) sqrt(%pi)/sqrt(1/σ^2)
No the result should have an absolute value in the answer, because sigma is always squared. The function exp (-(x/sigma)^2) will never be negative so the integral can never be negative even if x or sigma go negative.
No the result should have an absolute value in the answer, because sigma is always squared.
integration of a squared variable or abs of squared variable is not assumed to be positive.
This patch had nothing to do with the invert function plus Viktor only so far fixed only some rarely used metrics.
@robert_dodier @peterpall Can this be looked at for restoring the debug operations in WxMaxima. Only the single line :lisp operation works for debugging, because that is the only operation that will restore the prompt after the list-quiet operation clears the prompt. Hopeful this patch restores the prompt after the output for lisp-quiet is done. If the output is not finished then the only possibility is for each debug operation to restore the prompt before it starts. I have tested this with WxMaxima...
A fix for restoring wxMaxima prompt
Would this patch restore the Prompt after the list-quiet was finished so that all other debug functions will work? diff --git a/src/mdebug.lisp b/src/mdebug.lisp index 5385547..e498cda 100644 --- a/src/mdebug.lisp +++ b/src/mdebug.lisp @@ -640,6 +640,9 @@ (setq lisp-quiet-suppressed-prompt mread-prompt)) (setq mread-prompt "") (eval (cons 'progn l)) + (finish-output) ; wait and finish lisp-quiet output + (if (string= mread-prompt "") ; restore prompt + (setq mread-prompt lisp-quiet-suppressed-prompt))...
Would this patch restore the Prompt after the list-quiet was finished so that all other debug functions will work?
So it is now working!
I see this got changed in 2019 as follows;
@peterpall Gunter I think I found the issue in mdebug.lisp. A part of the file is below. lisp-quiet saves the mread-prompt in lisp-quiet-suppressed-prompt before lisp-quiet is executed. It does not restore it afterwards. It only gets restored after a lisp-eval function is called of the form in WxMaxima as :lisp ( atom $t); This is the only debugger function that works. All of the other debugger functions the mread-prompt is nil, because after each input statement WxMaxima calls list-quiet which clears...
@peterpall Gunter I think I found the issue in mdebug.lisp. A part of the file is below. lisp-quiet saves the mread-prompt in lisp-quiet-suppressed-prompt before lisp-quiet is executed. It does not restore it afterwards. It only gets restored after a lisp-eval function is called of the form in WxMaxima as :lisp ( atom $t); This is the only debugger function that works. All of the other debugger functions the mread-prompt is zero, because after each input statement WxMaxima calls list-quiet which...
After this build it is not getting the error anymore. wxMaxima version: 22.12.0-DevelopmentSnapshot_MSW using wxWidgets version: wxWidgets 3.2.1 Maxima version: branch_5_46_base_917_g9b044b688_dirty Maxima build date: 2023-01-02 00:11:47 Host type: x86_64-w64-mingw32 System type: Win32 10.0.19045 X86-64 Lisp implementation type: SBCL Lisp implementation version: 2.2.11 wxMaxima's idea of the directory layout is: User configuration dir: C:\Users\Richard.000/maxima/ Help dir: C:\maxima-current\sha...
I can't compile the program, so I need to use the complete installer at the nightly build web site.
I always use the nightly build from Wolfgang's web site and I am using windows 10 latest version. I also use SBCL.
I always use the nightly build from Wolfgang's web site and I am using windows 10 latest version.
This also does not work to run lisp code in WxMaxima by calling the following function to_lisp(); WxMaxima does not get back an indication for a lisp prompt just like in debug mode. So the the lisp call (to-maxima) would return to maxima coding. The attached file shows it works in command line mode, but not in Wxmaxima.
This also does not work to run lisp code in WxMaxima by calling the following function to_lisp(); WxMaxima does not get back a indication for a lisp prompt just like in debug mode. so the the lisp call (to-maxima) would return to maxima coding. The attached file shows it works in command line mode, but not in Wxmaxima.
Here is a command line example in windows. The attached file is a screen shot of the example where kill stops working after just the loading of to_poly_solve. Forgot to attach file.
Here is a command line example in windows. The attached file is a screen shot of the example where kill stops working after just the loading of to_poly_solve.
I see, if I type kill(to_poly_solve); The kill function will now work for other things. The next time to_poly_solve is used, it will need to be reloaded. There have been many changes to the global def variables list. There may have been a bug that cropped in related to this issue.
It happens in WxMaxima., in xMaxima, and also in command line mode Maxima.
The last example is in command line mode.
Here is an example. (%i1) eq1:a+b+c=5; (%o1) c + b + a = 5 (%i2) eq2:-c+6*b-a=0; (%o2) (- c) + 6 b - a = 0 (%i3) eq3:a+b=3; (%o3) b + a = 3 (%i4) load(to_poly_solve); (%o4) C:/maxima-current/share/maxima/branch_5_46_base_861_g0e585ea73_dirty/sha\ re/to_poly_solve/to_poly_solve.mac (%i5) to_poly_solve([eq1,eq2,eq3],[a,b,c]); (%o5) %union([a = 16/7, b = 5/7 c = 2]) (%i6) kill(eq3); Maxima encountered a Lisp error: The value $TO_POLY_SOLVE is not of type LIST
kill(exp) stops working after to_poly_solve is used once
Maxima does not work with WxMaxima so the the Debugger is usable.
@robert_dodier I see how to get the fork updated. I go to my fork in sourceforge. I click on the left margin the top item labeled Admin - Maxima -- GPL CAS based on DOE-MACSYMA - Code This will change the left margin to show different commands. The last command on the left margin is delete everything. The delete everything will kill the fork repository. Then I can create a new repository from the master code. This works. I also tried the refresh repository and it did not seem to do anything from...
@robert_dodier I see how to get the fork updated. I go to my fork in sourceforge. I click on the left margin the top item labeled Admin - Maxima -- GPL CAS based on DOE-MACSYMA - Code This will change the left margin to show different commands. The last command on the left margin is delete everything. The delete everything will kill the fork repository. Then I can create a new repository from the master code. This works. I also tried the refresh repository and it did not seem to do anything from...
@robert_dodier How do I update a fork or delete it to get a new fork when this patch is done?
How do I update a fork or delete it to get a new fork when this patch is done?
@robert_dodier I see @vttoth has not commented on this yet.
Changing a @code{dispsym} to a link @mref{dispsym} in itensore.texi
I saw in your paper Tensor Manipulation in GPL Maxima Feb. 1, 2008 that the frame bracket should be the following without the torsion. This would be in equation (50). (fri(a)i,k - fri(a)k,i)fr(b)^ifr(c)^k The exponents are contravariant indices other indices are covariant.
It might have been better to call the one Maxima uses a lfri for lowered fri like it is with Reimann and Einstein tensors and the general mixed coframe as fri like the mixed frame is fr. Then fr = transpose(invert(fri)) and not fr = transpose(invert(fri.ufg)) or fr = transpose(invert(lfri.ufg)) = transpose(invert(lfg.fri)).
It might have been better to call the one Maxima uses a lfri for lowered fri like it is with Reimann and Einstein tensors and the general mixed coframe as fri like the mixed frame is fr. Then fr = transpose(invert(fri)) and not fr = transpose(invert(ufg.fri)) or fr = transpose(invert(ufg.lfri)) = transpose(invert(fri)).
It might have been better to call the one Maxima uses a lfri for lowered fri like it is with Reimann and Einstein tensors and the general mixed coframe as fri like the mixed frame is fr. Then fr = invert(fri) and not fr = invert(ufg.fri) or fr = invert(ufg.lfri) = invert(fri).
It might have been better to call the one Maxima uses a lfri for lowered fri like it is with Reimann and Einstein tensors and the general mixed coframe as fri like the mixed frame is fr. Then fr = invert(fri) and not fr = invert(lfg.fri) or fr = invert(lfg.lfri) = invert(fri).
Tetrad.dem does not use the lowered coframe.
Here is example of using rules and set limits function. the limit to the atan2rule can also be-pi/2 to pi/2.
I think this is done after the link to the example in decsym is fixed. The reference to decsym should be the following @mref{decsym} as in canform.
I think this is done after the link to the example in decsym is fixed.
I think this is done.
I meant a double pair swap. 1,2 with 3,4 being 3,4,1,2 and the order of 1,2 does not change. 1,2 replaces 3,4 to give 3,4,1,2. The examples are here for Riemann tensor. Symmetry: Rαβγλ=Rγλαβ. Antisymmetry: Rαβγλ=−Rβαγλ and Rαβγλ=−Rαβλγ. Cyclic relation: Rαβγλ+Rαλβγ+Rαγλβ=0. The cyclic does not need to add any addition to make it zero. Maybe the other symmetries of the Riemann make it add to zero, but I don't know how to add the double pair symmetry I think I see it now. the symmetries are the following....
I meant a double pair swap. 1,2 with 3,4 being 3,4,1,2 and the order of 1,2 does not change. 1,2 replaces 3,4 to give 3,4,1,2. The examples are here for Riemann tensor. Symmetry: Rαβγλ=Rγλαβ. Antisymmetry: Rαβγλ=−Rβαγλ and Rαβγλ=−Rαβλγ. Cyclic relation: Rαβγλ+Rαλβγ+Rαγλβ=0. The cyclic does not need to add any addition to make it zero. Maybe the other symmetries of the Riemann make it add to zero, but I don't know how to add the double pair symmetry.
I meant a double pair swap. 1,2 with 3,4 being 3,4,1,2 and the order of 1,2 does not change. 1,2 replaces 3,4 to give 3,4,1,2. The examples are here for Riemann tensor. Symmetry: Rαβγλ=Rγλαβ. Cyclic relation: Rαβγλ+Rαλβγ+Rαγλβ=0. The cyclic does not need to add any addition to make it zero.
I meant a double pair swap. 1,2 with 3,4 being 3,4,1,2 and the order of 1,2 does not change. 1,2 replaces 3,4 to give 3,4,1,2.
I meant a double pair swap. 1,2 with 3,4 being 3,4,1,2.
Can declare symmetry define T_a,b,c,d to T_c,d,a,b where two pairs are swapped like in the Riemann tensor?
This bug turned out to be wxwidget posting an assert because wxMaxima was sending a string in the wrong coding.
Using a free falling frame, I show the different frame brackets and if they are like lcs.
Here is a wxMaxima version
Using a free falling frame, I show the different frame brackets and if the are like lcs.
I tested the different versions of the frame bracket from Itensor. They both give the Ricci rotation coefficients, but the frame_bracket function does not. Some of the indices of the diff function are wrong. The correction uses the ifb version with tr set to zero. Below is the correction with trigsimp added to convert each term. I did not see an easy way to add the ctrgsimp test flag. Maybe ratsimp would be better. frame_bracket(fr,fri,diagframe):=block ( for a thru dim do for b thru dim do for c...
I tested the different versions of the frame bracket from Itensor. They both give the Ricci rotation coefficients, but the frame_bracket function does not. Some of the indices of the diff function are wrong. The correction uses the ifb version with tr set to zero. Below is the correction with trigsimp added to convert each term. I did not see an easy way to add the ctrgsimp test flag. Maybe ratsimp would be better. frame_bracket(fr,fri,diagframe):=block ( for a thru dim do for b thru dim do for c...
I tested the different versions of the frame bracket from Itensor. They both give the Ricci rotation coefficients, but the frame_bracket function does not. some of the indices of the diff function are wrong. The correction uses the ifb version with tr set to zero. Below is the correction with trigsimp added to convert each term. I did not see an easy way to add the ctrgsimp test flag. Maybe ratsimp would be better. frame_bracket(fr,fri,diagframe):=block ( for a thru dim do for b thru dim do for c...
I ran a compare on ctensor.mac to check for any changes and I noticed the following: I think you did a typo when changing the f% in the frame_bracket. It got typed as %f instead, which is incorrect. Can you also check index ordering? Should it be the same as the ifb using the torsion tensor set to zero?
I have always wondered why constants were pulled out of integrals, which I thought was a bit weird. Now I know. I should study the simplification process a bit more. I would have thought the noun function would have priority over the simplification of the function. Thanks for simply work around.
Noun for integrate does not work for a constant
This is an updated patch which adds the function dispsym to the itensor.texi file. It would be nice if someone could add this to the master. Thanks,
Can this by added to the manual in itensor.texi? diff --git a/doc/info/Itensor.texi b/doc/info/Itensor.texi index e398020..e184c9b 100644 --- a/doc/info/Itensor.texi +++ b/doc/info/Itensor.texi @@ -1092,6 +1092,17 @@ @end deffn @c ----------------------------------------------------------------------------- +@anchor{dispsym} +@deffn {Function} dispsym (@var{tensor}, @var{m}, @var{n}) +Displays all of the defined symmetries from @var{tensor} which has @var{m} +covariant indices and @var{n} contravariant...
Can this by added to the manual in itensor.texi? diff --git a/doc/info/Itensor.texi b/doc/info/Itensor.texi index e398020..e184c9b 100644 --- a/doc/info/Itensor.texi +++ b/doc/info/Itensor.texi @@ -1092,6 +1092,17 @@ @end deffn @c ----------------------------------------------------------------------------- +@anchor{dispsym} +@deffn {Function} dispsym (@var{tensor}, @var{m}, @var{n}) +Displays all of the defined symmetries from @var{tensor} which has @var{m} +covariant indices and @var{n} contravariant...
Can this by added to the manual in itensor.texi? diff --git a/doc/info/Itensor.texi b/doc/info/Itensor.texi index e398020..e184c9b 100644 --- a/doc/info/Itensor.texi +++ b/doc/info/Itensor.texi @@ -1092,6 +1092,17 @@ @end deffn @c ----------------------------------------------------------------------------- +@anchor{dispsym} +@deffn {Function} dispsym (@var{tensor}, @var{m}, @var{n}) +Displays all of the defined symmetries from @var{tensor} which has @var{m} +covariant indices and @var{n} contravariant...
Add word to Integration.texi
I don't think there is any problem with the conversion of atan(tan(x)) to x, but the check still needs to be done that the resulting x needs to be in range of atan and that is -pi/2 to pi/2. This is necessary because the atan2 function added pi knowing that atan needed to be negative angle. It seems like the check of the resulting range of atan is not respected. The problem is that the atan(sin(7pi/13)/cos(7pi/13)) when reduced does not get atan(tan(x)). atan(tan(7pi/13)) does give -6pi/13.
I don't think there is any problem with the conversion of atan(tan(x)) to x, but the check still needs to be done that the resulting x needs to be in range of atan and that is -pi/2 to pi/2. This is necessary because the atan2 function added pi knowing that atan needed to be negative angle. Is seems like the check of the resulting range of atan is not respected. The problem is that the atan(sin(7pi/13)/cos(7pi/13)) when reduced does not get atan(tan(x)). atan(tan(7pi/13)) does give -6pi/13.
I don't think there is any problem with the conversion of atan(tan(x)) to x, but the check still needs to be done that the resulting x needs to be in range of atan and that is -pi/2 to pi/2. This is necessary because the atan2 function added pi knowing that atan needed to be negative angle. Is seems like the check of the resulting range of atan is not respected.
Ctensor perdefined spacetimes have incorrect coframes
English Manual String Proc a in place of an
dispsym is not defined in manual
I see the frame bracket like this works. When you call it like this frame_bracket(fr,fri,true); The indices for both fri tensors were swapped position so the global coordinate is the second index. frame_bracket(fr,fri,diagframe):=block ( for a thru dim do for b thru dim do for c thru dim do ( fb[a,b,c]:sum(sum(fr[b,e%](diff(fri[a,e%],ct_coords[f%])- diff(fri[a,f%],ct_coords[e%]))fr[c,f%],e%,1,dim),f%,1,dim), if ctrgsimp then fb[a,b,c]:trigsimp(fb[a,b,c]) ) );
I see the frame bracket like this works. When you call it like this. frame_bracket(fr,transpose(lfg.fri),true); The indices for both fri tensors were swapped position so the global coordinate is the second index. frame_bracket(fr,fri,diagframe):=block ( for a thru dim do for b thru dim do for c thru dim do ( fb[a,b,c]:sum(sum(fr[b,e%](diff(fri[a,e%],ct_coords[f%])- diff(fri[a,f%],ct_coords[e%]))fr[c,f%],e%,1,dim),f%,1,dim), if ctrgsimp then fb[a,b,c]:trigsimp(fb[a,b,c]) ) );
I have seen a similar result in other cases using ctensor and sqrt factors of differences. When radcan switches a sign of a factor in the sqrt to cancel with another factor, it should multiply the sqrt by i so that this sign change is remembered. If an even number of sign changes of divison were made the i s would cancel. but if an even number of sign changes of products made a square the result should be the product of two i , which will be minus and not a plus. If it chooses plus instead of minus...
Torsion is not used when cframe_flag is true
No worries.
Maxima manual displays ishow and show as the same function
How do you close the ticket?
Bug Posted in WxMaxima development site.
I have looked at this again. I think there is something happening when either the hodge or the levi civita function is called. After those calls, any time you need to enter a letter or letters at the demo prompt the demo crashes. It also causes the whole program to stop. This not only happens with the new Laplacian demo, but also with the hodge demo. I am not sure if this also happens with just the Maxima program. I use the WxMaxima version. I just tested only the Maxima command line and it seems...
I have looked at this again. I think there is something happening when either the hodge or the levi civita function is called. After those calls, any time you need to enter a letter or letters at the demo prompt the demo crashes. It also causes the whole program to stop. This not only happens with the new Laplacian demo, but also with the hodge demo. I am not sure if this also happens with just the Maxima program. I use the WxMaxima version.
I have looked at this again. I think there is something happening when either the hodge or the levi civita function is called. After those calls, any time you need to enter a letter or letters at the demo prompt the demo crashes. It also causes the whole program to stop. This not only happens with the new Laplacian demo, but also with the hodge demo.
I notice a question on the coframe indices used in the frame bracket. Shouldn't the local index c be in the first position to be compatible with the Maxima standard for the co-frame and frame to have the local index first. The current position as second index would not work for a non symmetrical co-frame where the transpose is not the same. It looks like the frame does have the local index first in this case.
Ok, I get it now. It is good. I see the ctensor code has only one version of the frame_bracket. Does that make sense? I have been trying to model teleparallel gravity with torsion and was trying to understand the torsion, frame bracket, curvature, and contorsion.
The document is definitely wrong, because the frame bracket does not have torsion in its calculation. The text in the gray box should not have the third term. the two descriptions of the two versions are not the same. The first document description has three terms with the itr included, which definitely is incorrect.
The document is definitely wrong, because the frame bracket does not have torsion in its calculation. The text in the gray box should not have the third term. the two descriptions of the two versions are not the same. The last document description has three terms with the itr included, which definitely is incorrect.
The document is definitely wrong, because the frame bracket does not have torsion in its calculation. The text in the gray box should not have the third term
The document is definitely wrong, because the frame bracket does not have torsion in its calculation. The text in the gray box should not have the third term
Manual equation for ifb incorrect.
coordinate_system='confocalellipsoidal' does not get lg from coframe.
Ctensor - leinstein does not use lfg when cframe flag is true.
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
Did you see this change or do I need to put this also as a bug report?