The largest known Mersenne primes have been found using a program named Prime95. It has been highly optimized over the years, with multicore support and use of AVX2 and FMA3 chipset extensions.

The 50th known Mersenne prime (2^77232917-1) took the Prime95 software 6 days to find on a quad-core Intel i5-6600 @3.3Ghz.

I suspect that one important question is whether isprime knows that your trying to do a primality test of a number with the particular form (ie, 2^p-1), and whether it would use a special approach if it did. So Maple might not end up doing something like this and, even if it did, the implementation would very likely not be nearly as well optimized as Prime95. So your machine might well take orders of magnitude more resources than did the machine which actually found the 50th known Mersenne prime.

It looks like you're using Maple 16.00.
 

Here's something...

Download 2_2.mw

Since you're interested in performance you should not be calling diff each time you call w2.

Try this,

w2:=unapply(diff(v2(x,y),x)-diff(u2(x,y),y),
            [x,y]);

If either diff(v2(x,y),x) or diff(u2(x,y),y) return something which contains something other than what you called an "explicit function" or an unevaluated diff call, etc, then show us the full example.

[edited] Below is an example where both u2(x,y) and diff(u2(x,y),y) return unevaluated for nonnumeric arguments x and y. In this case the above approach will not work. So the question becomes, how to evaluate the derivative of this "black box" (non-explicit) function numerically? One way is to use the fdiff command, and variant on that idea is to use evalf(D[..](...)) which has a kernel hook into fdiff.

Since you want the whole call to w2 to run under fast evalhf mode (since v2 might still run under it) then I'll use eval to allow the call to evalf(D[..](...)) to be called from within evalhf.

Download evalf_D.mw

If either of your u2 or v2 is the solution to a numeric pde problem (ie. coming from pdsolve numeric) then you might want to consider that the derivatives in question might be obtainable from the original differential equations (as some function of their terms, all supplied by the pdsolve solution). If so then that would likely be more numerically robust than using fdiff which is a numeric differentiation command and brings with it yet another layer of rough discretization.

The curves meet where the two expressions attain the same value, ie. where the difference of the two expressions is zero. So you're looking for the roots of BesselJ(0,x) - BesselJ(1,x) .

Student:-Calculus1:-Roots(BesselJ(0, x)-BesselJ(1, x), x=0..10, numeric);

            [1.434695651, 4.680102554, 7.836002335]

Here's a slightly more detailed look at it, considering just the first of the three roots:

ans := Student:-Calculus1:-Roots(BesselJ(0, x)-BesselJ(1, x), x=0..10, numeric);

         ans := [1.434695651, 4.680102554, 7.836002335]

x=ans[1];
                        x = 1.434695651

# Evaluate both expressions at that point. They are effectively equal.

eval( [ BesselJ(0, x), BesselJ(1, x)] , x=ans[1] );

                  [0.5479464494, 0.5479464495]

# Evaluate their difference at that point. It is effectively zero.

eval( BesselJ(0, x)-BesselJ(1, x), x=ans[1] );

                                 -10
                            -1 10   

That is not a bug.

By default LinearAlgebra arithmetic commands operate in hardware double precision. The computation of the 2nd entry in your result is similar to this:

restart;

HFloat(1.99987);

                        1.99987000000000
HFloat(-2.);

                              -2.

evalhf(HFloat(1.99987) + HFloat(-2.));

                    -0.000129999999999963478

Vector([%], datatype=float[8]);

                [-0.000129999999999963]

Note that neither 1.99987 nor -0.00013 is expressible as a hardware double precision float with "infinite" precision.

lprint( HFloat(1.99987) );
  HFloat(1.99987000000000004)

lprint( HFloat(-0.00013) );
  HFloat(-0.129999999999999989e-3)

If you want numeric LinearAlgebra operating with base-10 floats and "machine epsilon" like 10^(-Digits), rather with base-2 hardware floats with "machine epsilon" like evalhf(DBL_EPSILON), then you can force LinearAlgebra to operate in software floats rather than its default of hardware double precision floats.

You can do that by setting the UseHardwareFloats Maple envionment variable to false, or by raising Digits higher than 15 and leaving UseHardwareFloats at its default setting of deduced.

Download LA_Add_hw_sw.mw

What do you mean by "search interval"?

restart;
solve( {sin(sqrt(x))}, {x}, allsolutions );

                         /      2    2\ 
                        { x = Pi  _Z1  }
                         \            / 

about(_Z1);
  Originally _Z1, renamed _Z1~:
    is assumed to be: integer

restart;
Student:-Calculus1:-Roots( sin(sqrt(x)), x=0 .. 200 );

                 [     2      2      2       2]
                 [0, Pi , 4 Pi , 9 Pi , 16 Pi ]

restart;
Student:-Calculus1:-Roots( sin(sqrt(x)), x=80 .. 700 );

        [    2       2       2       2       2       2]
        [9 Pi , 16 Pi , 25 Pi , 36 Pi , 49 Pi , 64 Pi ]

Using an image for a plotted 3D surface can now be done using an option (ie. the image option).

But before that was possible, it could still be done more "manually".  See this old Post on mine, which has some examples with World map projections and even a few links for images of other planets surfaces. The technique was subsequently incorprated as new visualization functionality in Maple 18. Eg, with a user-friendly syntax,

plot3d(-1, t = -Pi .. Pi, p = 0 .. Pi,
       image = "http://www.maplesoft.com/data/examples/jpg/world.200412.400x200.jpg",
       lightmodel = none, coords = spherical, axes = none);

It is sad that the Help pages for the WorldMap functionality (new in Maple 2017) don't include any clear examples of how to display efficiently the DataSets,Builtin,WorldMap information on a 3D globe or sphere.

It is also sad that the Online Help doesn't have the new material from Maple 2016 and 2017 (it's 2018, folks).

In your Document I get right-click context menus to work OK on 2D Output, whether in a paragraph (Document Block) or an Execution Group.

But what doesn't work in your original is right-click context menus on 2D Input, whether in a paragraph (Document Block) or an Execution Group.

If I use the mouse to toggle "Show Command" on an offending Document Block, to reveal what the context-menu system inserted, then I see the expected command but with the placeholder %EXPR instead of the argument. Eg, solve(%EXPR, [b]) instead of solve(a=b+5, [b]) .

If I do all of the following then the right-click context menus work OK on 2D Input in your Document, for both new paragraphs and your two original paragraphs (Document Blocks):

1) Get rid of all the User Profile stuff in the Startup code region. I mean delete it all, not comment it out.
2) Get rid of the displayunit and outputmask attributes in the actual .mw file (manually).
3) Get rid of the UnitFormat-DefaultUnitFormat and NumericFormat-OutputMask in the View-Properties blob of the actual .mw file (manually).

So it looks like the combination of custom unit-formatting and custom numeric-formatting, loaded by the User Profile, are breaking context-menu actions for 2D Input (only).

You may have to give up on unit- and numeric formatting customizations from a User Profile, to get right-click context menus to work on 2D Input in new Documents with your Maple 2017.3. But context-menus might work regardless, on 2D Output.

note: You last saved your Document in Maple 2017.3, and I was working in Maple 2017.2 but it sounds like I was seeing the same issues as you were with your Document.

[edit] This may work as an alternative for a so-called User Profile. Take the key lines you want from your earlier Startup Code region, such as calls to the interface command for numeric formatting or the imaginary unit, and put them in the Startup Code region of a new blank Document. Don't copy over any of the lines mentioning User Profiles. Now save that blank Document somewhere permanent on your machine, and set it as the default "home" file, eg from the menubar Tools -> Options -> Interface -> Open worksheet at startup . If you do this then every time you open a New Document you should get a fresh copy of that customized template, with the entries in its Startup Code Region.

The f is not superfluous. You need to specify some numeric format (d, o, x, e, f, or g) in order to use z or Z.  The z or Z is just a modifier of that numeric format.

The reason that the "c" is in red in the Help page, where it describes "zc or Z", is that it is a placeholder (ie. it stands for the character you choose to type there).

One difference between "zc" and "Z" is that when modifying by Z you won't get the real and imaginary parts separated by anything other than the +/- sign of the imaginary component. The "zc" modifier allows you to separate them. Another difference it that using Z puts the imaginary unit at the end, whereas with zc it doesn't (but you can add it by hand).

If you only want to print both real and imaginary components together (separate by a single space, say), then it's as convenient to use the zc modifier as it is pass two values using Re and Im.

I mentioned that the Z modifier prints the current symbol for the imaginary unit. If you use the zc modifier and want to insert the imaginary unit in manually then you could even make it robust enough to also respect that setting.

Download printf_zcZ.mw

How about moving the line print('J'[n]=J[n]) to after the call to Jacobian, which constructs the Matrix and assigns it to J[n]?

Download q1nwtnnonlinearsys_1.mw

Don't make the mistake of trying to assign to f(x) .

Instead, assign the expression x^(3/2) to just f the name.

Download int_example.mw

The MatrixExponential command passes off to the MatrixFunction command, which in turn calls the Eigenvalues command.

If you convert the entries in H2 so that the coefficients are exact rationals then it works. (Or in you make all the entries floats, as in your H3, it works.) What it doesn't like are the symbolic names in entries with float coefficients.

Download MatrixExponential_rationalsymbolic.mw

The error message from Eigenvalues is being re-thrown usefully by MatrixFunction, but not by MatrixExponential.

It looks like Eigenvalues could in principle be made to succeed for your particular H2 example (but it might help MatrixFunction, and Eigenvectors it seems) if some simplification or other intermediate handling of the results were attempted.

[edited] It seems that conversion to trig form also works, even with the floats present. (I suppose it might just happen to do better because Eigenvalues does better with it.)

Download MatrixExponential_rationalsymbolic_2.mw

[edit] I should that the double-indexing approach is relatively much less efficient. And add will be more efficient than sum. So for larger examples you'd have the choice between prettier 2D input versus efficiency.

Download sumadd.mw

After assigning that value to the name complex1, then try,

convert(complex1, phasor);

You could also right click on the output of complex1 and choose the context-menu item Conversions->Phasor form...

Apart from not assigning to gamma and psi (because you want to solve for equations involving them), what's the particular difficulty?

If you don't want to declare gamma as a local name then change it to something else (eg, just g). Maple considers :-gamma to be a known constant (similar to how it knows what Pi is, etc).

Download fsolve_couple.mw