@Carl Love As Acer's Answer shows, my Answer is wrong. I was thinking of the inscribed ellipse of maximal area. I'm demoting the Answer to a Reply.

@janhardo Here is a very basic derivation. I've only used 4 very basic geometry formulas, all pertaining to right triangles and circles:

• sine of acute angle = (opposite side) / hypothenuse
• area of circle = Pi * radius^2
• Pythagorean formula: opposite^2 + adjacent^2 = hypothenuse^2
• area of right triangle = opposite*adjacent/2

The area of the chordal segment for chord length L is twice the shaded area shown. Clearly it's equal to the area of the radial sector outlined in red minus the area of the right triangle below the shaded region. By using the triangle's top side (L/2) and hypothenuse (R), the central angle of the sector is
theta:= arcsin((L/2)/R);

Thus the area of the sector is 
A__sector:= theta/(2*Pi)*Pi*R^2;

The area of the triangle is
A__triangle:= (L/2)*(sqrt(4*R^2-L^2)/2)/2;

So the area of a chordal segment is
AreaChord:= unapply(2*(A__sector - A__triangle), (L,R));

The rest is pretty much the same as the previous worksheet. Once again, MaplePrimes wouldn't display my worksheet, so please download it. The highlight is this highly symmetric formula for the desired overlap area:

r:= L/R: sq:= sqrt(1 - (r/2)^2):
A:= R^2*(r^2*arcsin(sq) + arcsin(sq*r) - sq*r);

Download Circles.mw

If the ellipse is inscribed in the rectangle, then its axes are necessarily determined by the midpoints of the rectangle's sides. In other words, the four points of tangency will be the midpoints of the sides. This should be enough for you to produce the plot. If you're still stuck, let me know.

@vv I'd recommend including a nonnegativity restriction when solving equations involving factorials:

floor(fsolve(1/(n+1)! = 0.0001, {n= 0..infinity})) + 1

Due to factorial's GAMMA extension, I've often obtained negative results when I forgot to include the restriction.

@rameen hamood Okay, my Answer is still valid.

Please give your Questions different and more-specific titles than "further linear algebra".

Please upload the worksheet by using the green uparrow on the toolbar. That way we can directly download it to our Maple.

@mthkvv 

You can speed up the coefficient arithmetic by exploiting the fact that the modulus is a power of two. Thus, the mod operation is just a bit truncation. Since GMP is open source, I'd start by looking there. It may just require a little tweaking.

I doubt that it's possible to gain any benefit from Schonhage-Strassen at this coefficient size. From my reading, the smallest coefficients that can benefit from S-S are order 2^(2^15).

@Adam Ledger Simply replace the second-to-last line with

ifactor:= ()-> orig_ifactor(({args} minus {':-easy'})[]):

@DarkMath How would it know that there's only one root unless it uses

solve({sin(x), -1 < x, x < 1}, x, explicit, allsolutions)

?

Using fewer options gives incorrect results for the root count (here I've widened the search interval):

solve({sin(x), -4 < x, x < 4}, x);
solve({sin(x), -4 < x, x < 4}, x, explicit);
solve({sin(x), -4 < x, x < 4}, x, allsolutions);

The first two give one root. The third gives countable infinity. So, given this, why would the integrator assume that "one root" was correct on the narrower interval? 

@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);