I'd like to point out for any readers who are not paying close attention that in your original Question, you asked about differentiating wrt x[i], while in your Reply to Markiyan, you changed that to x[j]. That changes the Question significantly. 

• The issue that I raised about bound variables no longer applies.
• The new problem can be solved by Maple if you're willing to make a few accommodations that seem relatively minor to me.

The accommodations are

• Change sum to int.
• Change x[i] to x(i) and x[j] to x(j).
• Change diff to Physics:-Fundiff.

So, the command is Physics:-Fundiff(int(sin(x(i)), i= 1..N), x(j)). The returned result is expressed in terms of Heaviside functions, and is essentially "cos(x(j)) if j is between 1 and N, otherwise 0".

It looks like you need a logarithmic plot. There are numerous options for those, with the most-significant distinction being which axis or axes contain the extreme values. See the help pages ?plot,axis, ?plots,logplot, ?plots,semilogplot, and ?plots,loglogplot.

You can put two plots (or any number of plots) side-by-side like this:

plots:-display( < graph | colorbar > );

Don't confuse this command with the ordinary plots:-display command, which merges multiple plots onto the same set of axes. This command literally places them side-by-side, each with its own set of axes.

I don't know how this will interact with EPS, but you can probably test that faster than I can.

There is a simple and universal way to deal with this situation: You refer to the placeholder Trace (the one used with evala) as :-Trace.

If you find this ugly or cumbersome, you only need to do it once. Choose a name that you don't find ugly or cumbersome, such as AlgTr, assign

AlgTr:= :-Trace;

and proceed to use AlgTr whenever you need it in the evala context.

The index i is a bound variable (see this Wikipedia article). As such, it doesn't make sense to use it to mean the same thing both inside and outside the context to which it is bound, which is the sum. Maple's syntax checker let's you get away with doing it without giving an error message, but the results are often nonsense.

The commands add, mul, and seq (which are all builtin and thus not written in the Maple language) have special rules that prevent their bound variables from being abused in this way. (Of course, they all never return unevaluated, which makes this easier.) This is not entireIy possible in Maple-language procedures. I advocate that the Maple language itself include a facility whereby a procedure can do the same thing, i.e., to declare that a name argument is a bound variable. The trickier part of this is how unevaluated returns (such as your sum) are handled. I think that the bound variables should be accessible to some low-level commands such as subs, but inaccessible to mathematically sophisticated commands such as eval and diff. This would be akin to the way that the internal contents of procedures can be manipulated by subs from outside the procedure.

One of the great things about Maple is that it's easy to convert from nearly any data format to nearly any other, and both the conversion and the use of the data can often be done together in a single line. So, you want a dataplot but it doesn't currently accept DataFrames or DataSeries? Then convert to lists via

dataplot(convert~([x,y], list)[]);

If the x-values are unsorted, then the connecting lines in the above plot will be nonsense. So, you can either make it a scatter plot or sort by the x-value. To make a scatter plot, do

dataplot(convert~([x,y], list)[], style= point);

To sort, do

dataplot(convert~([x[(P:= sort(x, output= permutation))], y[P]], list)[]);

Since the type specifications required for your work are getting lengthy and it'd be useful to use some recursive types, here is how it's done systematically. 

(This code requires Maple 2018.  If you're using earlier Maple, I can make a small change to make it work. Let me know.)

RohithExtract:= module()
uses TT= TypeTools, IN= InertForm;
local
   TryAddType:= proc(TH::(name::anything))
   local T:= lhs(TH), H:= rhs(TH);   
      if TT:-Exists(T) then TT:-RemoveType(T) fi;
      TT:-AddType(T,H)
   end proc,

   AddedTypes,

   ModuleLoad:= ()->
      TryAddType~(
         (AddedTypes:= [
            #With recursive types, put base cases at beginning to avoid infinite loops!
            'Atomic'::'Or'('name', 'numeric', 'InertReciprocal', 'Negated'),
            'InertReciprocal' :: (1 %/ 'Atomic'),
            'Negated' :: ((-1) &* 'Atomic'),
            'Operators'::'specfunc'('Atomic', {`%+`, `%*`, `%/`, `%^`}),
            'Rohith'::'And'('Operators', 'Not'('InertReciprocal'), 2 &under nops)
         ])
      ),

   ModuleUnload:= ()-> (TT:-RemoveType@lhs)~(AddedTypes),

   ModuleApply:= (E::string)-> value(indets(IN:-Parse(E), 'Rohith'))
;
   ModuleLoad()
end module:

And you use it like this:

RohithExtract("1/v[0]*V1+1");

Answering your first question, the mathsize option lets you specify the width and height of the response box in pixels.

Answering your second question, passing to (and even from!) the variables can be done in a quite general way with Grading:-Quiz:-Set and Grading:-Quiz:-Get like this

restart:
proc() 
uses GQ= Grading:-Quiz;
local r:= rand(2..20);
   GQ(
      "What is $a + $b?", 
      ()-> evalindets(`$RESPONSE` = `$a` + `$b`, name, GQ:-Get), #Checks answer
      ()-> evalindets([`$a`, `$b`]=~ ['r'()$2], `=`, GQ:-Set), #Generates random numbers for problem
      inertform, mathsize= [64,32]
   )
end proc
();

The $ and `` in the variable names are required, and `$RESPONSE` is a special receptacle name for the response. None of these can be local variables. I think that this is the form that you need to use if you want the randomized quantities to appear in the text of the question (which is what I mean by "quite general way"). The inertform is needed to prevent the quizzee from being able to get "Correct" by simply echoing the problem.

If the problem can be stated in the form expression = blank box, then Kitonum's formulation, which is simpler, can be used.

It is done by Typesetting:-mn(gcd)(x,y). This command is undocumented; however, if you enter exports(Typesetting), then in addition to the documented commands, you'll see many whose names begin with m. These are all commands for doing this sort of thing.

As Acer says, the extra prompts make no difference to the meaning of the code. On the other hand, with respect to editing the code, I find them quite a nuisance (you can't backspace over them) as well as ugly. When they appear in my code, I try to delete them as soon as possible. So, yes, I'd say that there's an advantage to not having extra prompts.

What purpose do they serve? Is there some reason that Maplesoft doesn't remove the prompt from the bottom group when execution groups are merged (aka joined)? Or is it just an oversight?

And this seems as good a place as any to remind people once again that restart commands should always be placed in their own execution group. Not doing do only occasionally causes problems, but those problems can be quite weird.

The error message indicates that your variable O[L] (or O__L) does not have units. The absence of units is considered the same thing as having 1 as the unit, as indicated by the message. If you replace O[L] by O[L]*Unit(kN), it should work. I can't test it unless you supply your actual code.

Your command print(whattype(df)) is leading you to believe that df has been converted from a Matrix into a procedure. In fact, it's still a Matrix. It's an idiosyncracy of print combined with the fact that the symbol Matrix is both a type and a procedure. If you use lprint instead of print, it'll say "Matrix".

I have many more suggestions for how you can improve your code, which we can go into. 

Any of the following commands will return ln(a+b*c), which is, I think, what you're asking for.

indets(expr, function(Not(function)))[];
indets(expr, anyfunc(Not(function)))[];
indets(expr, function({`+`, `*`}))[];
indets(expr, anyfunc({`+`, `*`}))[];

You need to give deeper (i.e., more complex, more profound, more nested) examples for me to refine the above commands. You say that you want the first, but there is no second in your example, so I cannot show you how to distinguish those.

Recalling your previous Question, I need to add: If you are processing the input through InertForm:-Parse, then the above commands need to be changed because then operators will be turned into functions, so the above commands will not distinguish between sin and `%+` for example.

Among the mathematical functions, special attention needs to be given to sqrt with respect to how it behaves with respect to your type of work: sqrt(x) is either simplified (assuming that x is some expression for which that is possible) or converted to x^(1/2) (or some combination of simplification and conversion to exponent form, as with sqrt(12)). So, if you search for sqrt in some expression that you just entered, you won't find it, it becomes an operator rather than a function. This can be prevented by using the inert form %sqrt rather than sqrt. As you may have guessed by now, every function f has an inert form %f. The command value is used to convert the inert forms to active forms (as I did in my Answer to your previous Question).
 

You can ask Maple:

is(cosh(x) <= exp(x^2/2)) assuming x::real;
      true

This can mostly be handled by InertForm:-Parse followed by some filtering with indets and a special structured type (that I composed just for this situation). Here's your example done:

value(
   indets(
      InertForm:-Parse("y = s + (a/b)*log((a+c/b))"), #string!
      #selects operators with exactly two operands, both of which are names,
      #integers, or floats:
      And(specfunc({name,numeric}, {`%+`, `%*`, `%/`}), 2 &under nops) 
   )
);
                             /a  c\ 
                            { -, - }
                             \b  b/ 

Note that the argument to Parse is a string. This prevents any automatic simplifications, thereby avoiding the problem mentioned by Preben.

I said mostly because the minus sign is treated differently in Maple, even by InertForm. It is always (effectively) an unary operator when applied to a symbolic expression. So, for example:

-1 is atomic (any negative explicit integer or float is atomic).
-a is stored as (-1)*a, even by InertForm.
a-b is stored as `%+`(a, (-1)*b), where `%+` is the inert operator in prefix form.
-a-b is stored as `%+`((-1)*a, (-1)*b).
-a-2*b is stored as `%+`((-1)*a, (-1)*`%*`(2, b)).
-2*a-2*b is stored as `%+`(`%*`(-2, a), (-1)*`%*`(2, b)).

As far as I can tell so far, there is no weirdness with the handling of fractions or complex numbers: They are deconstructed into `%operator`(operands) form in the way that you probably expect. You didn't mention exponentiation, so I didn't investigate that.

If you consider the last 2 of my 6 examples above, I think that you can imagine some of the problems and ambiguities that can arise. So, if we are to proceed, then you need to show many examples with minus signs and say for each how you would like it deconstructed.