@jmakinde For asterisk or cross you would use style=point (instead of linestyle=dot and the default style=line).

For example,

plots:-display(
  plots:-textplot([4.4,120,N(t)]),
  plots:-odeplot( sol7, [t, N(t), color = red,
                  style=point, symbol=asterisk, symbolsize=12],
                  0 .. 5, numpoints=30),
  labels = [t,N(t)], size=[475,400] );

The file has not been attached.

Do you want to shade or color the basin of attraction of a univariate equation when using Newton's method? Would that be as a function of the complex-valued starting point?

If so, do you want it shaded/colored according to which root it converges to (eg. here), or according to how many iterations it takes to converge (eg. here).

What is an example of your kind of equation? Does your equation contain special-function calls, or calls to non-evalhf'able procedures? Or, perhaps, it just involves rational polynomials, or...?

@ijuptilk The ways that were suggested apply the substituion process to all of the expression or to all of the coefficients of derivatives (possibly simplified). And, in a way, the offered solutions are concocted to "get lucky", in the sense that the subexpression for replacement doesn't occur anywhere else, but only as the coefficient of your chosen derivative.

For example, I'm guessing that you would not want this accidental result:

In general such an coincidental, unwanted substitution could also occur when using plain subs, if the target coeffcient also appeared elsewhere in the expression.

It seems that the spirit of your question may be to only substitute for the coefficient of your chosen derivative. So, straightforward and possibly more robust (in general) in the sense just mentioned,

@Carl Love Sorry, you're quite right. I had already tried simplify-with-side-relations, getting the same result as you. Hence I was expecting to see it in Tom's answer, and somehow misread his call.

@Carl Love Does that produce a result for you which is different from what Tom showed with his second approach, ie. simplify with side relations, without a third argument?

Please put your followup queries for this problem here, instead of spawning completely separate new Question threads on it.

@tomleslie Yes, internally NLPSolve finds a point at which the objective value is better (or improved). Yes, the error message states (cryptically) that, "no improved point could be found."  NLPSolve also requires a better objective value to meet some acceptance criteria in order for it to be returned as a solution.

NLPSolve throws an error here, rather than a warning alongside the better result which fails to meet the acceptance criteria.

This kind of programming conumdrum arises in Maple because mere warnings are not catchable programatically.

The developers of NLPSolve likely decided that it would be wrong to return a value (even if strictly better) that did not meet the acceptance criteria -- because that aspect could not be programatically detected in an adequately straightforward manner. (Who knows, perhaps if reimplemented today then the better value could get returned as part of a "solution module" which exported the value as well as incidentals and programatically accessible convergence/acceptance data and information.)

[edited] I'll try to offer some more concrete evidence. When the problematic example (nvar=2) is run in the OP's worksheet the problem is attempted using an external call to a wrapper which calls the e04uca NAG library function. The first attempt using evalhf-callback mode fails because procedure ss is not evalh'able. The second attempt using evalf-callback mode returns with that function's error-level code of value 6. The current Maple Library procedure Optimization:-External:-E04UCA then throws an error with the following error message:
     "no improved point could be found; consider increasing
      optimality tolerance and checking correctness of objective
      and nonlinear constraint functions"
That error is caught by a higher Optimization internal procedure and rethrown with the terser error message, "no improved point could be found".

See,
   showstat(Optimization:-External:-E04UCA,44..45);
   showstat(Optimization:-NLP:-SolveGeneral,40);

I do not know why someone thought it best to conflate several error cases like that, in NLP:-SolveGeneral.

That Nag error code is also described (in more detail, ie. for case ifail=6) here: e04ucf.html#errors   
Because the example involves the nested numeric computation of another process (with possibly loose accuracy or cruft trailing digits) I hazarded the supposition it was the (Nag-documented case) that raising optimalitytolerance might work.

The facts that either (only) raising optimalitytolerance or decreasing dsolve's "error" via relerr/abserr/Digits both succeeded is evidence that the cause is related as suggested. (Switching to a stiff ode solver might also fortuitously improve the dsolve result's accuracy enough to allow NLPSolve's default conditions to be met.)

IMO the above also indicates that merely finding some point which produces a better objective value is not sufficient to meet all the local optimality conditions. NLPSolve is intended to compute a locally optimal value, not just any old better value.

note: Sometimes I wrap local- or global-optimization problem's objective function in a procedure that retains the running best value/point in a global variable.

@tomleslie That error message doesn't mean that it didn't compute any better objective value altogether; it means that it did not compute a better objective value which also passes its acceptance criteria.

(I'd agree that that error message's wording could be improved. It can give the wrong impression, as evinced by your response.)

Please add your followup queries for this in a Reply here (or your other recent threads on this, here, or here), instead of spawning even more completely separate Question threads on this topic.

What have you been able to accomplish for this course-work question, so far?

@C_R I believe that the OP is asking how to programmatically obtain something as simple as his f__4, given the input p.

His question ends with, "Is there a way to get the much simplified result programmatically?" The instance of the definite pronoun "the" indicates "the much simplified result" as being a reference to the already obtained f__4. He's asked how to programmatically compute his superior f__4, not how to further improve it from what he's already obtained manually.

@jalal I don't see how you could easily programmatically and automatically connect up an arbitrary Grading:-Quiz embedded assembly with additional Components. The only ways I can think of (so far) involve more effort than basic re-implementation.

Part of the problem is that when you call Grading:-Quiz you don't know what will be the names/identities of the components that it will embed. So accessing, say, the MathContainer's randomly generated Limit example is trickier. It could likely be done by using a special global in the example-generating proc.

Another part of the problem is that Grading:-Quiz doesn't optionally return the raw XML that will embedded. So merging that with additional XML components (so as to get the whole, augmented assembly to be automatically embedded together) would be effort.

These are part of the rationale for thinking that it'd be easier to just reimplement this basic kind of Grading:-Quiz functionality, in your own mechanism that builds it all together.

@jalal Ok, so you need two Buttons, a MathContainer, and a TextArea. You can embed those from the palette. How far have you gotten with writing the action code behind the Buttons?

What are your actual requirements for connecting this to Grading:-Quiz, if at all?

Please add your close followup queries here, instead of spawning wholly separate Question threads that closely duplicate the topic.