@vv What you said about the 18 digits is true; however, not every possible sequence of 18 base-10 digits has a distinct representation as an hfloat, as your example posted immediately above shows. (In other words, your input and output both map to the same hfloat.) But every 15-digit number does map to a distinct hfloat, and 15 is the greatest integer for which this is true, which is why 15 is the standard returned by trunc(evalhf(Digits)).

You wrote:

• I don't see any contradiction using evalhf when Digits is 30. It could be e.g. a partial result, or a first approximation.

The OP's very first example clearly shows the nonsense that can result. Note that that first result is returned as an sfloat at 20 digits, not 18! Yes, it may be appropriate to use evalhf to get a first approximation, but (if using the results at the top level) you should change the value of Digits as you do it.

Don't repeat Questions as new Questions. They'll be deleted. If you want to raise your Question up in the "recents" stack, just post a followup Reply to it.

@emendes Your code is correct.

Your B could be made more efficient and more robust (easily extended to other situations) by 

op1:= {op~(1, parms)[]}:
B:= s-> {op~(1,s)[]} = op1:

There's no need to use S; you could use parms throughout.

The ,= is the new appending assignment operator. It's documented on help page ?assignment (or you can do simply ?,=).

@fatemeh1090 To try solve(..., parametric, real) with the new inequalities, they must be in polynomial form. The only one which isn't is u > 0, because of the sqrt in your specification of u. It can easily (by hand, for example) be shown to be equivalent to c*q+m > 0, which is polynomial​​​​​. If I put all those inequalties into the same solve that I had before, the command is

pwsol:= solve(
    {
       pp, 
       c*q+m > 0, 1+m-q > 0, q > 0, m > -1, m < 1, s > 0, c > 0,
       (1+m-q)^2 - 4*(m+c*q) > 0, q^2 + (-4*c-2*m-2)*q + (m-1)^2 >= 0
    }, 
    q, parametric, real
);

I let this command run (in Maple 2020) for over 3 hours of cputime and use 5 Gig of memory. Eventually it stopped due to some small bug. So, this is too complicated for the current capabilities of the command.

However, as I said, there are essentially only two possible solutions. The fact that you don't get 0 when you back-substitute them and simplify is largely irrelevant.

In conclusion, the title of this Question is incorrect in that there is no error at all in your results. Rather, it's the normal result of an equation with both a radical and parameters.

Other than the initial values, all the terms are of the form 3*2^m-1, not just the prime terms (modulo a small calculation error that you made).

@Jean-Claude Arbaut I was just about to post an Answer, but I see that you've already figured out what I was going to say.

What you called "type promotion" is often called floating-point contagion in Maple circles. In other words, once a symbolic expression has any float in it, symbolic expressions derived from it tend to become "infected" with even more floats. So, generally it's a bad idea to use evalf on expressions with free variables. But when you use seq, the numeric values of n are passed to u due to seq's special evaluation rule.

@emendes You will not be able to understand these until you understand the purpose of the selection-criterion procedure B from my previous examples!

Both of these methods produce the same list result. Both of them preserve the order in which the elements were generated.

restart:
S:= {'rand'()$9}:
B:= s-> s[1]::even:

# The Array method:
A:= Array(1..0): 
for C in Iterator:-Combination(nops(S), 6) do
    if B((s:= S[[seq(C+~1)]])) then A,= s fi
od:
L:= [seq(A)];

# The embedded-loop method: 
L:= [
    for C in Iterator:-Combination(nops(S), 6) do
        if B((s:= S[[seq(C+~1)]])) then s fi
    od
];

@fatemeh1090 Do you mean to consider those inequalities individually, or all at once?

For nondegenerate cases, there are only two possible solutions---the solutions that you already had. (Degenerate cases are when the parameters are such that the coefficient of q^2 in the minimal polynomial is 0.) All those hundreds of cases all amount to simply deciding, based on the parameters, which of those two solutions work in the original equation. The cases do not change the two solutions.

@emendes Your example doesn't work because you didn't define a procedure B. Like I said, B needs to be a procedure that returns true or false when passed a subset of S.

What's an .mm file?

@emendes The answer to your first question is an unequivocal "Yes, you can do the same thing using seq."

seq(S[[seq(C+~1)]], C= Iterator:-Combination(nops(S), 6))

The answer to your second question is more nuanced. Let's suppose that you have a "simple" boolean procedure B that returns true or false depending on whether you want to select the subset. By "simple", I mean that the procedure looks only at one subset at a time; it's not allowed to check the part of the sequence already selected. Then you can use seq to create a list like this

B1:= (s::set)-> `if`(B(s), s, NULL);
L:= [seq(B1(S[[seq(C+~1)]]), C= Iterator:-Combination(nops(S), 6))]

Now, let's admit the possibility that B is not simple. And, let's suppose that you want a list of all subsets that satisfy B, but you don't care about the order. In Maple 2017, the easiest efficient thing to do is

R:= table(): #optional, but recommended, table intialization
for C in Iterator:-Combination(nops(S), 6) do
    s:= S[[seq(C+~1)]];
    if B(s) then R[s]:= () fi; #entry is NULL; index is desired info.
od:
L:= [indices(R, 'nolist')]; #convert table indices to list

Never try to create a list, set, or sequence by adding one element at a time in a for-do loop! It is extremely inefficient. Instead, inside the loop, build a table or Array, and then convert it to a list, set, or sequence outside the loop.

Maple 2019 introduced several major syntax additions that make this easier.

Let me know if these satisfy your need.

I just Googled "GPS coordinates of London Metro stations", and the first hit had downloadable coordinates.

@acer You're right, of course. I just had trouble reading the fine print in the image, and I missed noticing the absence of the dash.

I don't see how this could be useful. The number of possible types is clearly infinite. One could check against all (non-parameterized) types for which code already exists, but what's the point of that?

Considering parameterized types opens up another dimension of complexity.

@Scythor Your error message above was caused by

G:= GT:-DrawGraph(...)

This makes G a plot, not a graph.

The vertex positions can be set explicitly with SetVertexPositions. Since you presumably already have a map of the Metro system, this shouldn't be too difficult. You could even use latitude and longitude coordinates.