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.) 

@C_R Thanks. I believe that the default simplifier is set up to avoid some of sophisticated but time‐consuming transformations that may make remarkable simplifications. (So I hope there will be a smarter approach to automatically simplify the second one in Maple.) 

@vv Thanks. I think there're (at least) 2 points: 

1. In practice, simply typing <…, …; …, …> is apparently more convenient than typing Matrix([[..., ...], [..., ...]])), and 
2. it appears that in this way one can access a new container (a Matrix) without constructing another temporary data structure (a list (of list)). 

@vv Thanks. The trouble is that neither special evaluation nor Construction Shortcuts mentions that `<,>` (as well as `<|>`) has special evaluation rules. Anyway, is there a direct way to force the arguments to be completely evaluated immediately (rather than being evaluated under the control of the procedure)?

@nm A simpler result of int(sin(x)^(1/3),x) seems to be , yet Maple cannot verify it: 

RealDomain:-simplify(diff(3/4*cos(x)/sqrt(cos(x)^2)*hypergeom([1/2, 2/3], [5/3], sin(x)^2)*sin(x)^(4/3), x) - sin(x)^(1/3));
 = 
1        (1/3) /                  /[3  5]  [8]        2\       2
-- sin(x)      |3 cos(x) hypergeom|[-, -], [-], sin(x) | sin(x) 
10             \                  \[2  3]  [3]         /        

                        /[1  2]  [5]        2\
   + 10 cos(x) hypergeom|[-, -], [-], sin(x) |
                        \[2  3]  [3]         /

                      \               
   - 10 signum(cos(x))| signum(cos(x))
                      /               


plot(%, x = -Pi .. Pi);

@Thomas Richard Thanks. After some experimentation, I find that after the normalization, one can directly use simplify rather than evalc＋combine:  

combine(evalc(normal(convert(sineExpr(4), exp), expanded)), trig);
   

simplify(normal(convert(sineExpr(4), exp), expanded), exp);
   

combine(evalc(normal(convert(sineExpr(5), exp), expanded)), trig);



simplify(normal(convert(sineExpr(5), exp), expanded), exp);

Anyway, your approach is still illuminating! 

@Christian Wolinski Actually, all of these functions are purely syntactical; none of them attempts to recognize hidden zero values 

m__1 := <allvalues(RootOf(_Z*(4*_Z^2 - 3)*((4*_Z + 1)^2 - 5) + 2))> -
    :-cos ~ (2*Pi/11*<2, 1, 3, 4, 5>):
ArrayTools:-IsZero(m__1);
 = 
                             false

andmap(is, m__1, 0);
 = 
                              FAIL

rtable_is_zero(m__1);
 = 
                             false

andmap(testeq, m__1);
 = 
                              FAIL

linalg:-iszero(m__1);
 = 
                             false

even if no nonzero item exists: 

radnormal~(convert~(m__1, RootOf)); # Each element is zero. 
                              [0]
                              [ ]
                              [0]
                              [ ]
                              [0]
                              [ ]
                              [0]
                              [ ]
                              [0]

I think this is partly because that kind of function is somewhat mathematically irrelevant to both linear algebra and matrix theory.

By the way, for a rtable, the most efficient command seems to be the undocumented rtable_is_zero: 

m__0 := Array((1 .. 1e2) $ 4): # not sparse 
CodeTools:-Usage(ArrayTools:-IsZero(m__0));
 = 
memory used=1.49KiB, alloc change=0 bytes, cpu time=25.00s, real time=25.07s, gc time=0ns

                              true

CodeTools:-Usage(andmap(`=`, m__0, 0));
 = 
memory used=6.71GiB, alloc change=0 bytes, cpu time=5.82m, real time=76.52s, gc time=5.27m

                              true

CodeTools:-Usage(rtable_is_zero(m__0));
 = 
memory used=1.14KiB, alloc change=0 bytes, cpu time=703.00ms, real time=704.00ms, gc time=0ns

                              true

CodeTools:-Usage(linalg:-iszero(m__0));
Error, (in linalg:-iszero) argument must be a matrix or a vector 

 (The elasped time appears to be the "real time" instead of the "cpu time".) 

Sorry, what is the exact meaning of the term "twin"? (For example, what is the relationship between 1 and [4, 5]? I cannot find any relationship between 2 and [9, 12].) 

@acer Thanks. These are really good ideas. But oddly enough, your second replacement rule for m = 4 works in the version released ten years ago! And the execution time in Maple 18 is far less than that in the latest version (although your first approach is still more efficient). 
 

Download sinId_acce.mw

 Regretfully, the same result of P2_real(4) cannot be reproduced in recent versions (e.g., Maple 2024); this indisputably implies a terrible performance regression. (Actually, some scholars recently stated that “for certain trigonometric computations, Maple is less effective”, which is likely due to such a performance regression.) 

@Scot Gould According to DLMF, at least those hypergeometric functions in my initial example doesn't need the valuable to be limited to non-negative. As for the assumptions, I think this could be due to the following reasons: Though the result given by Mma contains the natural logarithm and the cosine integral, and the two are not defined for non-positive real values, the difference between them (namely, ln(x)－Ci(x)) has no singularities or discontinuities in (-∞, 0], which might be more usable (especially in physics and engineering). 

I think that this is because a real solution is missing (without any warning message): 

ode:=diff(y(x),x)=3*x*(y(x)-1)^(1/3):
ic:=y(3)=-7:
y(x)=1-(x^2-5)^(3/2); # the lost solution 
                    

odetest(`%`,[map(convert,ode,surd),ic],y(x)) assuming x^2>=5;
                             [0, 0]