sursumCorda

1174 Reputation

13 Badges

2 years, 76 days

MaplePrimes Activity


These are replies submitted by sursumCorda

@Thomas Richard Thanks. Anyway, the default font of the code editor window seems to be more recognizable. 

@Thomas Richard What is the default font used by the code editor? The default font used by the code edit region seems to be Courier New, while the default font used by the code editor window (including the Startup Code region and certain component properties editor) appears to be Consolas. May you confirm this? (BTW, why are the two not consistent?)

Code edit region: 
Code editor window: 

@nm Thanks. I noticed another weird problem: 

MmaTranslator:-FromMma("!a->b//@c");
 = 
                                 (1/2)
                         a = c(b)     

MmaTranslator:-FromMma("!!a->b//d");
 = 
                        `read`(a->b//d)

However, the output should be convert( and convert( instead of convert( and convert(
It seems that I have to always use the less readable FullForm as input to the translator. 

@Samir Khan Many thanks! I hope this is useful in some cases.

@vv It's in `convert/to_special_function`, yet I don't think it's very useful in practice. 

@acer Thank you for your reminder. I forgot that I had changed the default “output display” option before. 
I believe that Maple has an internal function to appropriately abbreviate repeated common subexpressions in large output, yet I cannot find it. (As you said, the codegen:-optimize often over-optimizes common subexpressions, which is not the default behavior of "subexpression labeling".) 

@acer Sometimes the documentation seems to tend to describe those subtle things too briefly. Anyway, thanks for your valuable comments! 

@acer Sorry for the late reply. I try to find a simpler example, yet ended up with nothing. 

Well, here is the nested integral: 

expr := (x + Pi/2) - (Pi/(2*sqrt(3))*sin(x) + Pi/2*cos(x) + 2*x*sin(x/2)):
simplify(combine(1/4*sin(x)*int(1/cos(x1/2)**2*int(cos(x2/2)**2/sin(x2/2)**3*int(sin(x3/2)/(1 + sin(x3/2))*int((1 + sin(x4/2))*(2*sin(x4/2) - 1) + x4/2*(cos(x4/2) + sin(x4)), x4 = 0 .. x3), x3 = 0 .. x2), x2 = x1 .. Pi), x1 = Pi/3 .. x)) - expr) assuming RealRange(Open(Pi/3), Open(Pi));
simplify(combine(1/4*sin(x)*int(1/cos(x/2)**2*int(cos(x/2)**2/sin(x/2)**3*int(sin(x/2)/(1 + sin(x/2))*int((1 + sin(x/2))*(2*sin(x/2) - 1) + x/2*(cos(x/2) + sin(x)), x = 0 .. x), x = 0 .. x), x = x .. Pi), x = Pi/3 .. x)) - expr, assume = RealRange(Open(Pi/3), Open(Pi)));

Ideally, both results should be 0, but in fact, there will be several WARNING messages. 
At last, I have to use 

assume(Pi/3 < x, x < Pi):
simplify(combine(1/4*sin(x)*int(1/cos(x/2)**2*int(cos(x/2)**2/sin(x/2)**3*int(sin(x/2)/(1 + sin(x/2))*int((1 + sin(x/2))*(2*sin(x/2) - 1) + x/2*(cos(x/2) + sin(x)), x = 0 .. x), x = 0 .. x), x = x .. Pi), x = Pi/3 .. x)) - expr);

or 

undefine('x'): # free from `assume` 
`assuming`([simplify(combine(1/4*sin(x)*int(unapply(1/cos(x/2)**2*int(unapply(cos(x/2)**2/sin(x/2)**3*int(unapply(sin(x/2)/(1 + sin(x/2))*int(unapply((1 + sin(x/2))*(2*sin(x/2) - 1) + x/2*(cos(x/2) + sin(x)), x), 0 .. x), x), 0 .. x), x), x .. Pi), x), Pi/3 .. x)) - expr)], [Pi/3 < x, x < Pi]);

Besides, the help page states that 

the assuming command does not place assumptions on dummy integration variables in definite integrals …, 

while I notice that assuming does not appear to strictly distinguish between the bound variables (i.e., the variables of integration) and free variables (e.g., the limits of integration) in definite integrals whenever there exists a possibility of confusion like duplication of names: 

int(…*int(…*int(…*…, x = 0 .. x), x = 0 .. x), x = 0 .. x) assuming x::…:

In my opinion, setting global assumptions (using assume) may be convenient but also dangerous; perhaps the limitation that no assumptions are placed on the variables when using assuming can be disabled in future releases. 

@acer Thanks for your detailed reply. But there exists an addition problem. If int is not invoked when executing coulditbe (or is), why is the returned value below still true

trace(int):
coulditbe(x = 1) assuming 0 < x, x < 1;
 = 
                             false

int(RETURN(coulditbe(x = 1)), x = 0 .. x) assuming 0 < x, x < 1;
 = 
                              true

Although this is just confusing … in my opinion, as the int procedure has not been called yet, no renaming of the formal parameter (i.e., the red x in the first argument) is done at this time; nevertheless, the result is still true. Did I miss something again? 

(Note. My original problems originate from the calculation of nested integrals, but I think that the simplified version above is enough to illustrate the problem.) 

@Carl Love Thanks. The use of RETURN is only to print out the corresponding operation results without exceptions (or unnecessary output), since there will be an error if I use print instead. (Besides, so far as I know, although the ERROR function has been deprecated, using the error statement must require more keystrokes here.) 

@nm Regular expressions can still be used, yet the problem is that so far as I know currently Maple does not support the so-called “tokens”; however, you may execute the following code in Mma

In[1]:= sp[s_String] :=
            StringReplace[RegularExpression["(?s)^(.*?)\\\\textrm({(?>(?2)|[^}{])*})(.*+)$"
                ] \[RuleDelayed] StringTemplate["``\\begin{minipage}{\\linewidth}\\textrm``\\end{minipage}``",
                 InsertionFunction \[Rule] #0]["$1", "$2", "$3"]][#]&[s]

In[2]:= sp["0{0\\textrm{11}\\textrm{2\\textrm{33}2\\textrm{44}2}0}endl"]

Out[2]= 0{0\begin{minipage}{\linewidth}\textrm{11}\end{minipage}\begin{minipage}{\linewidth}\textrm{2\b\
 
>    egin{minipage}{\linewidth}\textrm{33}\end{minipage}2\begin{minipage}{\linewidth}\textrm{44}\end{mi\
 
>    nipage}2}\end{minipage}0}endl

Has this bug been fixed? It appears that it can still be reproduced in Maple 2024. 

@dharr Thanks for your reply. The typo has been fixed. 

@dharr Thanks. After reading A bug of Minpoly?, it seems better to manually convert algebraic objects into RootOf representation beforehand. Anyhow, I believe that there must exist a bug in PolynomialTools:-MinimalPolynomial (because no warning message is issued during execution). 

@Christian Wolinski Thanks. But I think this doesn't meet the requirement, since all of coefficients are expected to be rational. (Note that the constant term of your F (as a polynomial in lambda) is an irrational algebraic number.) 

1 2 3 4 5 6 7 Last Page 3 of 22