@Carl Love Reaching for the eliminate command seems the natural thing to do here. But it looks as if there's something to fix, because the following returns the empty set instead of restrictions on the remaining name k.

That is, I am seeing this,

restart;

eqs:={-6*c+(3/2)*c^2-2*b-3*b*c+(3/2)*b^2-3*a*c+(k^2)*b-b+(3/2)*(a^2)+(k^2)*a-a=0,
      -2*b-3*b*c+3*(b^2)-6*a*c+2*(k^2)*c-2*c-9*a*b+3*(k^2)*b-3*b+6*(a^2)+4*(k^2)*a-4*a=0,
      (3/2)*(b^2)-3*a*c+(k^2)*c-c-9*a*b+3*(k^2)*b-3*b+9*(a^2)+6*(k^2)*a-a=0,
      -3*a*b+(k^2)*b-b+6*(a^2)+4*(k^2)*a-4*a=0, 
      (3/2)*(a^2)+(k^2)*a-a=0}:

eliminate(eqs, {a,b,c}):

           [{a = (1/3)*k^2-1/3, b = 0, c = 0}, {}]

But I would have expected something with a restriction on k in one part of the result, say something like this,

    [{a = 0, b = 0, c = 0}, {}],

    [{a = (1/3)*k^2-1/3, b = 0, c = 4}, { k^2 - 1 }]

The difference between Maple 16.02 and Maple 17.02 is that frac(Pi^22) is no longer being returned as (the same) unevaluated frac call. I completely missed that before.

Eg,

restart;            
kernelopts(version);

      Maple 16.02, X86 64 LINUX, Nov 18 2012, Build ID 788210

frac(Pi^22);

                             22
                      frac(Pi  )

versus,

restart;            
kernelopts(version);

        Maple 17.02, X86 64 LINUX, Sep 5 2013, Build ID 872941

frac(Pi^22);

                        22
                       Pi   - 86556004191

So the difference is Library side (rather than any change in the underlying kernel-extension mechanism, AFAIK). So with the current control-flow (and with frac(Pi^22) returning just Pi^22-86556004439 ) it's not clear at what point the frac computation could be intercepted and Digits adequately raised internally (see Carl's exposition) so that evalf(frac(Pi^22)) would return an answer accurate to inbound Digits.

@ecterrab I wrote a comment here which I've now deleted. I missed the fact that, in Maple 17.02 onwards, frac(Pi^22) is no longer returning unevaluated as it did in Maple 16.02.

I like vv's idea of approaching the problem via a parameterization.

The real and imaginary components of the original can be plotted, for some insight. It's harder for implicitplot if those are two surfaces which intersect along a curve at height z=0. And it's harder still if either of them only touches z=0 without crossing it.

Using fsolve can work, provided there is only one relevant solution p for each b (or vice versa), and if fsolve can always find the desired other real coordinate value (eg, when called with its complex option).

Here a a few more brief considerations:

impl3.mw

@Earl The earliest version of the Explore command saw it get so-called special evaluation rules. In particular the first formal parameter of the Explore:-ModuleApply procedure (ie. the expression being explored) is specified uneval.

That brings the shallow benefit that one does not need to use single right-quotes (aka uneval quotes) to prevent the first argument from being prematurely evaluated. I call it shallow because it also prevents assigned names in the explored expression (here, the equations in sys, the assigned names within them, the procedure fric, etc) from resolving to their values unless special examination and evaluation is done internally by the procedure.

In Maple 2018 the internals of Explore go to some effort to try and resolve the assigned names. It mostly works¹.

In Maple 2016 and older there are some alternatives. One alternative is to create a wrapping procedure (which can, when called, get the needed evaluation via scoping), and this is why the ?examples,Explore example worksheet has several examples with simple wrapping procedures. Another alternative is to use some suitably placed uneval quotes, and wrap with a call to eval, and I attach that below.

382483three_reservoir_prob_ac_2016.mw

Sorry for the long-winded explanation.

¹⁾ After 25 years working with Maple I've become convinced that it is not possible to implement (as interpreted, Library code) exactly the same kind of evaluation of procedure arguments as the kernel can effect. So such extra efforts can never be made to work entirely.

An implementation of ithprime could utilize a stored collection of (suitably placed) primes and their ordinates.

When called with argument n the procedure would find the largest stored ordinal less than or equal to n. And then it could start the `isprime` from the corresponding stored prime (if n were not a stored value).

Storing 1 million integer[8] values takes only about 8Mb in memory. 

An appliable module could load the precomputed values from a binary file, when being defined.

Perhaps a fun project.

@Carl Love The setting is saved as a preference automatically.

Why do you want to make the whole legend be just a single string?

Why cannot you use either of these? (Are you using an old version of Maple?)

legend = [omega[0]=omega0]

legend = [`ω`[0]=omega0]

@David Sycamore By "argument" Tom is referring to n when ithprime(n) is called.

It looks like a relevant procedure here is `latex/latex/*`.

If one of the operands of the expression (of type `*`) were of type `fraction` then its own operands (1st and 2nd) should be concatenated as LaTeX (rather than multiplied, as Maple multiplicands) with the other (possibly bracketed) numerator and denominator LaTeX bits. That's to avoid automatic simplification. Eg. we don't want a denominator of 2*(x^3+3*z) to automatically simplify to (2*x^3+6*z) before it gets tex'ified.  Eg, we wouldn't want this:

_LatexSmallFractionConstant:=1:

latex( -(3/2)/(x^3+3*z) );

  -{\frac {3}{2\,{x}^{3}+6\,z}}

It might be possible as a surgical hot-fix (ToInert, subsop of the edit, and FromInert, so as to not violate copyright). That might depend on how involved and extensive the edit were.

@Carl Love The change in semantics that you describe came about in Maple 2015.0, it seems. I don't see it described in either ?updates,Maple2015,compatibility or ?updates,Maple2015,Language .

I'd like to clarify that, while the syntax change you've mentioned is of related interest, this is not the cause of the original problem with procedure f as reported in this thread.

It certainly is interesting that orthopoly:-H(n,x) can now be used instead of orthopoly[':-H] , but I interpreted the original question as being more about how to write the procedure so that the calls to H could be written with just the short form of the name (and that being set up in a centralized manner).

Personally I don't envision myself ever electing to use the syntax orthopoly:-H(n,x) over orthopoly[':-H] since that unnecesarily blurs the fact that it's a reference to a table-based package (and the distinction may matter in some other way, like with uses).

This is the kind of question where it can really help to provide at least one complete example  (whether larger/longer/more involved, etc) that fully illustrates the set of difficulties you're having as well any additional details about the domain.

Otherwise people can just waste time trying to provide suggestions that help only with the toy example.

If you are generating the data from within Maple itself then you can store it in a Matrix.

Within that same session you can then directly access those values for use in further computations, and there is no absolutely no need to export it to a file.

If you need to access the data from another Maple session (eg. after restart, or from another worksheet) then you can use ExportMatrix in the original session and ImportMatrix in the subsequent sessions.

@Carl Love 

Very nice.

I'll just add one minor note, if that's OK.

By default those Sliders with float ranges will each have the Component property "Continuous Update on Drag" toggled on. That means that the GUI will send the underlying code (here, the numeric bvp solution procedure) more than a single call as the Slider is dragged. But the computation of each of these plots, for each passed value/call, takes a little while. So as one moves the Slider these computations can pile up in a queue, and this can make this exploration seem clunkier. However the "Continuous Update" property can be toggled off for each Slider. The result of doing so is that the bvp solver only gets called once per adjustment of the slider (when you stop moving and release it). You may find the over responsiveness a little better for this intensive example, with that setting.

For example,

Explore(
   OneFrame(C__1, C__2, C__3, C__4, C__5),
   parameters=[ seq([rng, continuous=false],
                     rng=[
     C__1= 1.2e8..1.8e8,
     C__2= 2e9..10e9,
     C__3= 2e8..6e8,
     C__4= 0..5e7,
     C__5= 3e7..5e7
                         ]) ],
   widthmode= percentage, width= 100 
);

Of course, as you mention, it's also possible to reduce the value passed for numpoints. (Or that value could also be another explored parameter.)

[edit] The continuous-update property of an exploration Slider can also be adjusted, post-insertion, by right-click on the Slider.

@nm Yes, I mean the Programming Guide.

Try using LibraryTools:-Save, and always supply the name of the desired, existing archive (string) as the last argument (instead of relying on savelibname).

You are of course free to use whatever you prefer, that works for you.

If you go with savelib then watch out for stray .m files produced if it doesn't find a writable .mla archive. (A .m file will not contain a full and functional module, but just its shell which is of no use.)