@DarkMath They are ineffective in general. I suspect that the reason is that they can always be worked-around by using eval as I showed.

@DarkMath I think that it'd be called a weakness rather than a bug (because the returned valued isn't incorrect). My guess is that the integrator fails to use the (explicit, allsolutions) combination of options. I discovered the effectiveness of this combination in 2016 by experimentation, before it was documentated in the help pages. I may have written something about it in MaplePrimes at that time; I can't recall. Anyway, this option combination is relatively new, so it may not be coded into the integrator.

If it is known a priori that the function is "odd" (aka antisymmetric), then I don't see any point in attempting to fit both branches simultaneously.

@emendes Assuming that all work is being done on a single computer^[*1], I don't see much point in using Grid and Threads together. The table T1 is inherently "shared memory", thus making Threads the natural choice for the line doing the searches.

[*1] Grid does have a facility for distributing work over several computers. I believe that you need to pay MapleSoft something extra to get this functionality.

@emendes Certainly, copying the list as a table uses more memory than your original approach. If the original list L1 contains no duplicates, then the table contains all the information needed to reconstruct the list, and the L1 can be sent to the garbage collector:

T1:= table(sparse, L1=~[$1..nops(L1)]):
L1:= 'L1':
Threads:-Map[2](index, T1, L2);

@mthkvv Yes, I'm familiar with those multiplication algorithms.

There are two kinds of multiplication to consider here: The multiplication of the polynomials and the underlying multiplication of the integer coefficients. The integer arithmetic is handled by GMP (see Wikipedia article). The package is extremely efficiency conscious, and you'll not be able to beat it. It uses a polyalgorithmic approach---choosing the multiplication algorithm depending on the size of the factors. I believe that it switches to Schonhage-Strassen for factors larger than about 33,000 decimal digits.

Regarding the polynomial multiplication: Some experiments can be done to estimate the order of time complexity as a function of the number of terms. 

@mmcdara Algebraic functions can also have different horizontal asymptotes on the left and right. Example:

x/sqrt(x^2+1).

@Adam Ledger wrote:

• ok great but ifactor is definately inbuilt though, right?

No, it is not; it is written in Maple.

• And the radnormal in line two can be removed, it makes no difference.

Right, it seems that the equality check (which I guess is processed by PiecewiseTools:-Is) forces a call to radnormal anyway.

• how can i set ifactor to attempt all possible methods before giving up, and have that globalled applied to all usage of ifactor throughout the worksheet?

It's a great question, and, amazingly enough, it can be easily accomplished in Maple. The following just strips all options from all ifactor calls:

restart:
orig_ifactor:= eval(ifactor):
unprotect(ifactor):
ifactor:= n-> orig_ifactor(n):
protect(ifactor): protect(orig_ifactor):

If you just want to strip the easy option, that's possible also. Of course, your code will take much longer to run.

@DarkMath Yes, the ability of solve and assuming or assume to work with each other is awkward at best. This is described a few places in solve's help. In particular, assumptions on the bound variables (the variables being solved for), including general number-class assumptions like real, either don't work at all or work weirdly. 

To use options explicit and allsolutions together, do

solve({sin(x), -3/2*Pi < x, x < 3/2*Pi}, x, real, explicit, allsolutions);

@tomleslie wrote:

• [T]his site probably(?) isn't the place to receive tuition on basic Maple coding/syntax.

I vehemently disagree. While these issues may be particularly frustrating for those of us who write answers here, the attempts to do so are quite beneficial to our own progress as educators.

If there existed another online forum where basic Maple coding and syntax were discussed, I'd be more inclined to agree with you.

This phenomenon doesn't happen in Maple 2020. Nonetheless, try adding the option optionsopen= [color= "Nautical 1"]. This is because the region being plotted is topologically open (defined by strict inequalities).

You're using both x1, y1, z1 (2nd character is numeral 1) and xl, yl, zl (2nd character is lowercase "ell") as subscripts. Is that what you intend? It's very difficult to read in 2D input; I needed to zoom to 200% to discern them. If you want to use the letter, please make it uppercase L.

@mthkvv My guess is that you'd be hard pressed to beat the speed of modp1 computations, even using compiled code. But I guess that you intend to do a large number of these computations, lest 4 seconds wouldn't be a problem. Perhaps efficiencies can be found by avoiding some repetition? For example, the ConvertIn only needs to be done once for each polynomial.

I think that you attached the wrong worksheet. The one that you attached has no alpha and no Explore.

This section of the Wikipedia article "Ellipse" has explicit (and simple) formulas for all 6 coefficients of the equation of any ellipse in the xy-plane, parameterized by the center, the rotation angle, and the axes' lengths.

If the ellipse is not centered at the origin, then the formula is not quite as simple as you suggest, but neither is it significantly more complicated.