Couldn't you at least try to rewrite your homework problems in your own words? and come up with a better title? Your style is lame.

I find that rewriting a problem often makes me realize the solution.

@Ramakrishnan Thank you so much for catching that. I've now corrected the Answer. As you've probably guessed, I originally used A in both places, but at the last moment changed the name in the definition to Angle for clarity.

@dharr The computational effort required for gridrefine=n is an exponential function of n in both time and memory. The highest that I've ever used was gridrefine=5.

@acer I get your point, and combined with the OPs later comments, I see that maximally consistent subsets aren't sufficient. 

Suppose that the equations were {a=1, a=2, b=3}. Then I think now that the desired subset is {b=3}. But I don't see how to generalize that to cases where the "good" variables and "bad" variables are mixed in the same equations. 

@emendes Would it be sufficient to find a maximally consistent subset?

You wrote, "otherwise maple needlessly spend time for finding the gcd." 

I don't believe that unless you can show me an example.

Given: polynomials p, q, and f where f is a previously known common divisor of p and q.

Algorithm A: Compute GCD(p/f, q/f).
Algorithm B: Compute GCD(p,q)/f.

Can you show me an example where A is faster than B?

@Ugurgozutok If the polynomial is not integer, then the situation may be hopeless. What kind of coefficients do you have? For decimal coefficients, you may be able to find an approximate factorization with the SNAP package (see ?SNAP). I don't have any experience using it with parameters (such as your d).

My algorithm above does not care whether the polynomial is linear in d, but it does require that both d and the coefficients be integer.

@Carl Love I just updated the example in my Answer. It's a 20-digit (67-bit) value of d found in 2.3 seconds.

@Axel Vogt While a=0 wasn't part of the domain in the original formulation of the problem, it makes no sense epistemologically in this case to not consider the closure of that domain. Thus, I see the original formulation as flawed. And, "reading between the lines", it seems that it was also ad hoc.

While from a purely mathematical perspective it does make sense to not consider the closure of the domain and to thus say that there is no minimum, that approach seems pedantic and not very useful.

Also there won't be much hope even for a numeric result if the domain is not a compact hyper-rectangle (a cartesian product of closed, bounded intervals).

Do you mean that you want to find the roots, zeros, or x-intercepts (they all mean essentially the same thing) of a function and list them in a table? You should post a worksheet. 

I just substantially shortened the above procedure.

@nm The ambiguity of VV's example is that if one wanted a string containing an embedded string whose first and last characters were commas, then it would be impossible to represent that under the supposed rules that you've shown so far.

Maple has different "formats" (the %-codes) for printing out "ordinary" strings, strings that are appropriately escaped to be reread as strings, and strings that are appropriately escaped to be reread as strings in the context of CSV. Here are four examples:

data:= [1, 2, 3, "x+y, algorithm=[\",123,\"]", "OK", 5];
     data := [1, 2, 3, "x+y, algorithm=[",123,"]", "OK", 5]

sprintf("%a", data); parse(%);
       "[1, 2, 3, "x+y, algorithm=[\",123,\"]", "OK", 5]"
         [1, 2, 3, "x+y, algorithm=[",123,"]", "OK", 5]

sprintf("%A", data); parse(%);
          "[1, 2, 3, x+y, algorithm=[",123,"], OK, 5]"
         [1, 2, 3, x + y, algorithm = [",123,"], OK, 5]

sprintf("%v", data); parse;
        ""[1, 2, 3, x+y, algorithm=[\",123,\"], OK, 5]""
          "[1, 2, 3, x+y, algorithm=[",123,"], OK, 5]"

sprintf("%V", data); parse(%);
        ""[1, 2, 3, x+y, algorithm=["",123,""], OK, 5]""
          "[1, 2, 3, x+y, algorithm=[",123,"], OK, 5]"

It seems that only the %a worked here in a way that would be useful for your case. So you should see if Mathematica has a way to print out appropriately escaped strings.

For the existing files, we might need to write a conversion utility and do them all. The fact that there are thousands of them is not a big issue.

@Christopher2222 Yes, and if you're happy with those tickmarks on the y-axis, then great, that's all there is to it! Personally, I prefer "rounder" numbers for tickmarks.

You're absolutely right that the index -1 represents the last character of a string, -2 represents the second-to-last character, etc. What you show is an outright bug in UpperCase, etc., that's been glaring from that help page since at least Maple 2016 (the oldest that I have on this computer).