@Carl Love That is very unfortunate programming of the Java GUI.

(I spend so much time in the commandline interface that I reflexively think of its sane behaviour as "the normal manner".)

I will submit a bug report.

@Carl Love I agree with what you've written, except that I don't see it respecting interface(verboseproc) in the usual manner.

@pik1432 FYI, two solutions for the new system can also be found (quickly) as follows:

RootFinding:-Isolate(evalf[100]((lhs-rhs)~([f1,f2,f3,f4,f5,f6,f7,f8,f9,f10])),
                     [vars[]],maxroots=3,digits=20);

Q_ac_20200811_ac2.mw

You could start by providing us with details of what you did to obtain this.

You can upload and attach a Worksheet to a Comment or Question here. Use the green up-arrow in the Mapleprimes editor.

@Reshu Gupta 

G:=x -> -1.50000000000*x - 0.0170454545454*(x^4 + 17.6721666667*x^2
 - 5.11042142857)*x - 0.0197950153310*exp(-4.47213595500*x)
 + 0.0197950153310*exp(4.47213595500*x)
 + 6.62030572935*10^(-13)*(-92400.*x^4 - 82645.0724484*x^3 + 526680.*x^2
  + 241736.836912*x + 27027.)*exp(-4.47213595500*x + 4.47213595500)
  + 6.62030572935*10^(-13)*(92400.*x^4 - 82645.0724484*x^3 - 526680.*x^2
  + 241736.836912*x - 27027.)*exp(4.47213595500*x + 4.47213595500):
V:=Vector([seq(G(x),x=[seq(-1..1,0.1)])]):
P1:=plot(<<[seq(-1..1,0.1)]>|V>,style=point):
P2:=plot(G,-1..1):
plots:-display(P1,P2);
ExcelTools:-Export(V, "foo.xls");

@nm Debugging your example is easier at first, since one can trace or stopat the signum command, starting with argument  1/sin(x).

That  leads to Re(x) under the assumption. But Re is a kernel builtin, so showstat and stopat appear to be a dead end. However, some kernel builtins will also call back out to Library commands. By setting printlevel:=999: you can tell how the kernel calls back into the Library, for this example, and continue on with Library-side debugging techniques.

It gets a little awkward, as you have to also dispel the chaff after setting printlevel:=1: again. But it's workable.

So, I traced signum to find that Re(x) assuming x::{} returned 0. Then I used higher printlevel to see (fortunately) where the kernel happened to call back into the Library.

Your original question was about why the (accidental) use of assuming {} produced the division by zero error, since you had already corrected your syntax for using `assuming` in prefix form.

But for fun, a few other ways to get the more compact tan form result,

restart;

u1 := -ln(csc(x)-cot(x));

                   u1 := -ln(csc(x) - cot(x))

subs(X=x/2,convert(simplify(convert(subs(x=2*X,u1),tan)),tan));

                            /   /1  \\
                         -ln|tan|- x||
                            \   \2  //

[sin(x)=trigsubs(sin(x),trigidentity="Double Angle")[1]]:
convert(simplify(subs(%,simplify(u1))),tan);


                            /   /1  \\
                         -ln|tan|- x||
                            \   \2  //

[csc(x)=trigsubs(csc(x),trigidentity="Double Angle")[1],
 cot(x)=trigsubs(cot(x),trigidentity="Double Angle")[1]]:
convert(simplify(subs(%,u1)),tan);

                            /   /1  \\
                         -ln|tan|- x||
                            \   \2  //

@DoingMath2018 You are welcome.

I'm not sure whether there is an example of this in the documentation. I know that Robert Israel has an old note on it here.

I will submit a bug report, suggesting a clarifying example under the plotting Help pages.

@pik1432 I am not sure how you obtained your versions of f9 and f10, but below I have adjusted them. Then I obtain solutions using both the new and the old equations (and check against both for residuals).

I also show how procedures may be constructed from the equations, which each locally raise Digits for their own calculations, which I mentioned earlier.

I also compute an apparant second solution. (One of the solutions is picky about the supplied ranges.)

I don't know precisely why solve is not finding the solution for this reformulation, but I'm not sure that it matters so much as fsolve can be used.

Download Q_ac_20200811_ac.mw

Upload and attach your worksheet using the green up-arrow in the Mapleprimes editor.

@Scot Gould He has Maple 18, in which version your call to rand is not supported.

I have changed the "Product" label on your Question from Maple 2018 to Maple 18, since the latter is the version in which your attachments were last saved.

Maple 18 was released in the year 2014, and is four major releases old than Maple 2018.

I have deleted your duplicate Post in which you complain, without example, of the quality of the Maple GUI.

I deleted it because it is no more than a duplicate of this Post.

If you have additional details of your issues and frustrations, then post them here.

Are you using 2D Input mode, in a Document, which is the default for new users the GUI?

If so, have you tried 1D Input (plaintext "Maple Notation") mode, in a Worksheet?

Those can be set as preferences under Tools->Options in the GUI's main menubar. That is,
  1) Tools->Options->Display and toggle the "Input display" combobox entry to "Maple Notation".
  2) Tools->Options->Interface and toggle "Default format for new worksheets" to "Worksheet"

I am just guessing here. Copying input code can be problematic in 2D Input mode, since the GUI's editing facility insists it knows better and can offer only copying what it thinks are parsable portions of a larger 2D Input block. In 1D Input mode it is much more amenable to sub-selecting and copying -- ie. it allows pretty much any subselection from a block of plaintext code.

If you prefer plaintext coding, you could also utilize so-called Code-Edit Regions within a Document. But if you also have issues with Document navigation then 1D Input + Worksheet may be preferable.

The more specifics you can provide about your code editing issues the more we might be able to help.

@Scot Gould I find type realcons to be useful, because it should allow you to know that you can hit the scalar value with evalf and obtain a float.

For example,

type( sqrt(2), realcons );
              true
type( Pi, realcons );
              true