@Markiyan Hirnyk No, you are wrong. The question specified the error allowed in sin(x) as being 0.5. Part b) asks how big xerror the error in x can be while still allowing 0.5 error in sin(x) to be attained. The fact that they may be the same (both 0.5) might be related through error bounding the truncated series.

@Markiyan Hirnyk Yes, you used an xerror of 0.5 in exp(x) to get sin(x+-xerror) correct to within 0.5. You have not given any explanation about how you decided that Digits=100 or xerror=0.5 was sufficient, however. My answer is about why that value of xerror is sufficient, and about why Digits=44 is the least necessary working precision to get evalf(exp(100)) correct to enough decimal digits (which relates to xerror, given some rounding details) so that the sin result can get the required accuracy.

I deliberately left out an approximation of sin(exp(exp(100))) if using `sin` as for the smaller example, because I suspect that this is coursework, but gave what I consider a hint about it. Parts a) and b) are related.

@Markiyan Hirnyk How does taking the log base 10 inside the call to sin address the question? The question asks about sin(exp(100) and sin(exp(exp(100))), so how do sin(log[10](exp(100))) and sin(log[10](exp(exp(100)))) relate to answering that?

@Markiyan Hirnyk The answer to the first sentence in b) is that it depends on the magnitude of x. How it depends on that is something that the answerer might attempt to discover, and I suppose that is an implicit part of the question. Bounding the error in x in order to get a sufficient condition that sin(x) has error less than 0.5 seems reasonable to me. I don't want to give a complete answer to what seems like coursework. The latter part of b) is about sin(x) where x=exp(100) and x=exp(exp(100)).

@Markiyan Hirnyk No, the post you cited does not contain the answer to this simple question, I believe. It's a shame that you have confused this thread with it, and worse still that you made it a Comment on the Question so that its irrelevance sticks to the top of the thread.

I interpret the Question here as being about how to set up a Slider component that controls the value of a Plot component. Ie, the Poster is getting to know the basics of embedded components, and trying to clear up some simple but understandable misconceptions. Advanced techniques, such as in the page you cited, don't help with that.

@Carl Love Actually, one can assign an operator that way in 2D Math. A disambiguation dialogue window pops up, and the two choices are function definition and remember table assignment.

It can also be set as a preference using Typesetting:-RuleAssistant or Typesetting:-Settings.

However, the choice is not necessarily saved with the worksheet, and someone else running the sheet later on might not know how to choose in order for all subsequent code to proceed as intended. It might be less unhelpful if the user (or the GUI?!) inserted a preliminary call like Typesetting:-Settings(functionassign=true) when that form of operator assignment gets used.

It's confusing if people try and post 2D Math source here as plaintext, because there are some significant syntactic differences.

404 - File or directory not found.

acer

@Sujaan Kunalan The code I posted was for Maple 17. You could make the high and low values to be 0.005 and 1.0 say, in the pop-up dialgue. That should be enough, to change. (It probably won't like the default low value of 0, since it will try and use that as an initial stepsize.)

@Gruyere In your first line that attempt to initialize brotSet you use only = instead of := for as assignment. So that line just creates an equation, and didn't assign to the name. It sounds like you typed it in properly when you entered it on another line.

@Mac Dude Yes, I had understood. I had thought that Carl's suggestions would not be enough, alone, because of the remaining premature evaluation of the elementwise multiplication -- even before you confirmed that in your followup. Sorry for not being clear, before.

Try quoting the whole thing inside the list that is the second parameter passed to plots:-animate, ie.

plots:-animate(Statistics:-Histogram,
               ['dR*~WindowN(RP0,Can,CangleWidth+Can),ignore=true,view=[-0.5..0.2,0..10]'],
               Can=-0.1 .. 0.1);

If that doesn't work, try making it a postfix call to elementwise multiply, where that operator (but not the whole function call) is uneval quoted. That would need to be accompanied by either of Carl's earlier suggestions. Ie, (if I type it in right...)

plots:-animate(Statistics:-Histogram,
               ['`~`[`*`]'(dR, ` $`, 'WindowN(RP0, Can, CangleWidth+Can)'),
                ignore=true,view=[-0.5..0.2,0..10]],
               Can=-0.1 .. 0.1);

nb. there's a mix of single left- and single right-quotes in there.

@Mac Dude Did you intend for those uneval quotes to delay the elementwise multiplication with Vector dR?

@sunit If your expression read from .m is `eqnl1x` then what does,

   indets(eqnl1x,`local`);

return?

@Babak 

restart:

P0:=plot(x^2,x=0..2,color=red):

P1:=plottools:-reflect(P0,[[0,0],[0,1]]):

P2:=plottools:-transform((a,b)->[-a,b])(P0):

plots:-display(Array([P0,P2,P1]));

plots:-display(P0,P1);

plots:-display(P0,P2);

@nm Mapleprimes had similar functionality, in its first few years.

@Markiyan Hirnyk If one wants to execute the 2D Math Input containing the doubly underscored 4 then it should be an atomic identifier (because otherwise the 2D parser has no uderstanding of it, as syntax). Note that Maple doesn't do so much with this computationally, since it's interpreted just as a name and not as something mathematically related to the number four.

But if the 2D Input is only used as typeset math without execution (eg. inlined as math within some text paragraph) then it is not necessary to convert to atomic identifier, I believe.