Although the help page of `convert/rational` does not mention its internal algorithm, the help page of `identify` (which is mentioned in the help page of `convert/rational` in fact) does mention: 

In view of this, it is reasonable to infer that internally, rational approximations are obtained among continued fraction convergents, that is, generated by truncating continued fraction expansions. 

However, I think that a more hard task is to recognize an "simplest" algebraic number that approximates a given (probably floating-point) number well. (For instance, 

evalf[10**3](root(2, 6) + root(3, 5)):
identify(%, 'BasisSizeAlg' = 30);

still fails to recover RootOf(_Z^30 - 18*_Z^25 - 10*_Z^24 + 135*_Z^20 - 7380*_Z^19 + 40*_Z^18 - 540*_Z^15 - 135540*_Z^14 - 56160*_Z^13 - 80*_Z^12 + 1215*_Z^10 - 336420*_Z^9 + 538380*_Z^8 - 43920*_Z^7 + 80*_Z^6 - 1458*_Z^5 - 102060*_Z^4 - 98280*_Z^3 - 20520*_Z^2 - 1440*_Z + 697, index = 2).)

@Carl Love Thanks. Strangely, Maple's R&D engineers seem to have overlooked this (probably because the Maple IDE project (not the code edit region component) has already been aborted).

@Carl Love Yes, I can change it myself. But I believe it would be better to automatically set its default value based on different computer screen sizes when installing Maple, so that by default, if I want to send a document including a full-line lprint to others with wider screen computers, I don’t have to add a statement like interface('screenwidth' = 9999): in the startup code or request them (mostly ordinary users) to change their own initial settings. 

@Carl Love Many thanks. Maybe the default screen-width can be changed to a larger number in modern Maple.

@Carl Love Thanks. But in both "the most recent release" and "some legacy version", the interface(screenwidth) is set to the default value 79. Why is the output in the latter still wider than that in the former? 

@acer Thanks for your commentaries. This scheme looks feasible, but I found that it may make the code less intuitive (if I have understood correctly?). Perhaps there will be a better way to achieve this in the future so that the size and complexity of the code can be minimized.

@Carl Love Thanks for your explanation. Anyway, I hope that Maple can maintain a unified parameter structure.

@nm Thanks. I have fixed it.

@acer Maybe my previous problem Why does `applyrule` fail to apply rules? - MaplePrimes is relevant to this. @Christian Wolinski has provided a workaround using pattern-based applyrule, but I'd like to know how to translate the original (and in my view, easy-to-read) 

applyrule([s(x::anything)(y::anything)(z::anything) = x(z)(y(z)), 
                        k(x::anything)(y::anything) = x, 
                                     i(x::anything) = x], 
          [s(k(s(i)))(s(k(k))(i))(x)(y)), 
           s(s(s)(s))(s)(s(s))(k), 
           s(s(s))(s)(s)(s)(s(s)(k(k)))]); # This does not work. 

into the language of evalindets/subsindets.
Here, s(x::anything)(y::anything)(z::anything) can be translated to typefunc(anything,typefunc(anything,specfunc(anything,s))), and k(x::anything)(y::anything) can be translated to typefunc(anything, k(anything)); nevertheless, according to the documentation of evalindets/subsindets, the second parameter cannot be a list, so I can only input one rule at a time (while there exist three rules). How to make them accept three rules as the arguments at a time (just like what applyrule (as well as define) does)?

@acer Thanks. I believe that it should be converted into a new question. Maybe your valuable replies can be moved there.

@mmcdara Many thanks. The second way is much cleaner. (I don't want to break lines because the plot structure may have further uses.) Perhaps there should be a more convenient way to do so in future releases.

@mmcdara Thanks. I think that sometimes there can be an additional problem: Without breaking the line segments, what if I want the red line to be below the blue area and above the red area, and the blue line to be below the red area and above the blue area?

@nm Though Maple does make use of the GNU MPFR library, according to the official website of this library, there seem to be certain subtle differences between them: Comparison of multiple-precision floating-point software. The computation in raw MPFR library is much faster than that in Maple; does Maple just partly use GNU MPFR? 
[moderator: this comparison is out-of-date by over fourteen years]

Edit. Sorry for this outdated citation, but I cannot find a newer one in its official website. (Note that the latest version I can find contains neither Maple nor Mma.)

It should be: 

eq2:=-17=eval(diff(sol,t),t=4);
expand(simplify(eq2));

Edit. Sorry for another typo; 'parametric' is unnecessary here.

Since 2018, one can also evaluate “Python:-Start():” and call Python's state-of-the-art SDP solvers purely in Maple; regrettably, the communication overhead is rather heavy (at least on my low-end PC). (However, as neither the "GlobalOptimization" add-on nor the "DirectSearch" toolbox deals with such optimization problems, the dependence upon MatLab/Python seems inevitable at present.)