There is no attachment to your post, at this moment.

@dman This first set produces a residual error upon forward resubstitution like what you obtained above:

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 100:
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 14:
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 100:
allmod := map(t->10^t, all):

Digits := 100:
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[5](check);

                        [167.71, 403.17]

This next variant gets a much smaller residual that was obtained in the previous variant. The only differences are in the values assigned to Digits. If you reduce the value assigned to `Digits` at any of the markers A, B, C, or D then the residual error for the check will get larger. Of those, the action right after marker B is very influential: B marks the Digits setting which controls to how many decimal digits the root approximations held in the list `all` get rounded.

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 30: # A
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 30: # B
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 30: # C
allmod := map(t->10^t, all):

Digits := 30: # D
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[10](check);

                   [        -14          -14]
                   [1.471 10   , 5.040 10   ]

And next comes evidence that indicates that, no matter how high the working precision set at markers A, C, and D, the residual error computed in the check is limited and directly connected to the number of digits to which the root approximations `all` are rounded at marker B.

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 500: # A
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 30: # B
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 500: # C
allmod := map(t->10^t, all):

Digits := 500: # D
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[10](check);

             [              -14                -14]
             [1.418451742 10   , 4.888485464 10   ]

@dman This first set produces a residual error upon forward resubstitution like what you obtained above:

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 100:
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 14:
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 100:
allmod := map(t->10^t, all):

Digits := 100:
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[5](check);

                        [167.71, 403.17]

This next variant gets a much smaller residual that was obtained in the previous variant. The only differences are in the values assigned to Digits. If you reduce the value assigned to `Digits` at any of the markers A, B, C, or D then the residual error for the check will get larger. Of those, the action right after marker B is very influential: B marks the Digits setting which controls to how many decimal digits the root approximations held in the list `all` get rounded.

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 30: # A
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 30: # B
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 30: # C
allmod := map(t->10^t, all):

Digits := 30: # D
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[10](check);

                   [        -14          -14]
                   [1.471 10   , 5.040 10   ]

And next comes evidence that indicates that, no matter how high the working precision set at markers A, C, and D, the residual error computed in the check is limited and directly connected to the number of digits to which the root approximations `all` are rounded at marker B.

restart:
eq := (0.178e-1)*x*tan(0.2e-4*sqrt(x))^2 = 0.232e13-x:
neweq := subs(x=10^y, eq):

Digits := 500: # A
newans := Student:-Calculus1:-Roots(neweq,
                                    y=log[10](10^10)..log[10](10^11)):
newans2 := Student:-Calculus1:-Roots(simplify((rhs-lhs)(neweq)),
                                     y=log[10](10^10)..log[10](10^11)):

Digits := 30: # B
all := [op(evalf({op(newans), op(newans2)}))]:

Digits := 500: # C
allmod := map(t->10^t, all):

Digits := 500: # D
check := map(t->eval((rhs-lhs)(eq), x = t), allmod):

evalf[10](check);

             [              -14                -14]
             [1.418451742 10   , 4.888485464 10   ]

@OxidisedLizard What is the value of w, which appears in that version of func that you've posted above?

Could you possibly help make another check of the correctness of the form of func? Could you post the plaintext result of running the command lprint(func) at the point in your workflow right before you successfully plot it?

Thanks a ton.

@dman It is a mistake to think that you can round `newans` and `newans2` down to 14 digits (producing `all` in consequence) and then expect 10 raised to the power of those rounded values to satisfy the original equations (no matter how high you make the working precision for the powering and the last check).

Also, you may have to do the Roots calculation at higher working precision as well.

Raise Digits both before you do the Roots calculation and also do not severly round down the results of that.

It can be the case trhat the forward error check can produce values much larger than zero even when there are 14 or 15 correct digits in the answer here.

Some of this is more about numerical analysis than it is about Maple.

@dman It is a mistake to think that you can round `newans` and `newans2` down to 14 digits (producing `all` in consequence) and then expect 10 raised to the power of those rounded values to satisfy the original equations (no matter how high you make the working precision for the powering and the last check).

Also, you may have to do the Roots calculation at higher working precision as well.

Raise Digits both before you do the Roots calculation and also do not severly round down the results of that.

It can be the case trhat the forward error check can produce values much larger than zero even when there are 14 or 15 correct digits in the answer here.

Some of this is more about numerical analysis than it is about Maple.

@mitko 

Why do you want to assign something to `x`?

restart:
with(codegen, C, makeproc):

out := x[2]^2 + x[1]:

test_file := makeproc(out,x::array(1..2)):

C(test_file, optimized);
#include 
double test_file(x)
double x[2];
{
  double t2;
  {
    t2 = x[1]*x[1];
    return(t2+x[0]);
  }
}

Alternatively,

restart:
with(codegen, C, makeproc):

x:=table([]):

out := x[2]^2 + x[1]:

test_file := makeproc(out,x::array(1..2)):

C(test_file, optimized);
#include 
double test_file(x)
double x[2];
{
  double t2;
  {
    t2 = x[1]*x[1];
    return(t2+x[0]);
  }
}

@mitko 

Why do you want to assign something to `x`?

restart:
with(codegen, C, makeproc):

out := x[2]^2 + x[1]:

test_file := makeproc(out,x::array(1..2)):

C(test_file, optimized);
#include 
double test_file(x)
double x[2];
{
  double t2;
  {
    t2 = x[1]*x[1];
    return(t2+x[0]);
  }
}

Alternatively,

restart:
with(codegen, C, makeproc):

x:=table([]):

out := x[2]^2 + x[1]:

test_file := makeproc(out,x::array(1..2)):

C(test_file, optimized);
#include 
double test_file(x)
double x[2];
{
  double t2;
  {
    t2 = x[1]*x[1];
    return(t2+x[0]);
  }
}

@AliKhan Sorry, but I can make no sense out of your comment.

Why don't you post a Comment on your original Question for this topic, in which you write down as plaintext 1D code a short but explicit and representative example containing both an input expression and the expected result.

@AliKhan Sorry, but I can make no sense out of your comment.

Why don't you post a Comment on your original Question for this topic, in which you write down as plaintext 1D code a short but explicit and representative example containing both an input expression and the expected result.

@mgu What I did was pretty much the same as what Preben did with

   solve(%,{_C5});
   res:=eval(res1,%);

except that I used limit instead of 2-argument eval in order to evaluate as x=0. There can be some difficulties for eval used in that way (if numerator and denominator of some expression both evaluate to zero) and so using limit can sometimes be more robust. So I used limit, while it might not have been strictly necessary for this example.

There was no reason for me to use limit only from the right. That was just a holdover by cut'n'paste, from your earlier example involving ln(x).

A difference between my version and Preben's answer in this thread is that he explicitly wrote down a very simplified formula which could be solved for _C5, while I got Maple to form and use it. That might be because a little luck was needed to get that result. I found that Maple would not do the limit unless the result from solve was simplified "enough". And I only got that to work by doing simplify(...,size), while plain old simplify(...) did not get it. These may be hints as to why this task could be difficult in general, and perhaps might even hint as to why that other assume/assuming attempt failed for this example.

@mgu What I did was pretty much the same as what Preben did with

   solve(%,{_C5});
   res:=eval(res1,%);

except that I used limit instead of 2-argument eval in order to evaluate as x=0. There can be some difficulties for eval used in that way (if numerator and denominator of some expression both evaluate to zero) and so using limit can sometimes be more robust. So I used limit, while it might not have been strictly necessary for this example.

There was no reason for me to use limit only from the right. That was just a holdover by cut'n'paste, from your earlier example involving ln(x).

A difference between my version and Preben's answer in this thread is that he explicitly wrote down a very simplified formula which could be solved for _C5, while I got Maple to form and use it. That might be because a little luck was needed to get that result. I found that Maple would not do the limit unless the result from solve was simplified "enough". And I only got that to work by doing simplify(...,size), while plain old simplify(...) did not get it. These may be hints as to why this task could be difficult in general, and perhaps might even hint as to why that other assume/assuming attempt failed for this example.

Instead of creating an entirely new thread, you could use the "branch" link at the end of a followup Comment, to to it into a new Question. This has the benefit that the two threads automatically get cross-referencing links, so that the audience can see both if they wish.

@Jarekkk I'm sorry!

Silly me I completely overlooked that part of the question.

@Jarekkk I'm sorry!

Silly me I completely overlooked that part of the question.