@fluff That should be "end proc" not "ens proc".

And "randomize()" rather than "rendomize()" which does nothing.

And your proc's parameter name is "switch" but in the code you use "switches".

@Syeda The equations do not appear to have a solution for x when z is not a value above 1.249642 or so. You have now used z=1, for which there may be no root. When fsolve returns unevaluated it means that it has not found what it considers to be a root.

@Syeda Can you not just use fsolve?

Eg,

fsolve(eval(rhs(eq1)-rhs(eq2),z=1.2497),x);

                        0.0008311824617

@Carl Love Thanks, Carl, I had misread the exponents. But it only affects the result a small amount, and the the minimal z for which there is a root is still greater than 1 (or 0.5044).

I have edited my answer accordingly.

@john125 I am not aware of a technique that can always find the regions of convergence, which can be multiple and quite seperated. After fiddling with the Gaussian map (see here) I wrote a crude procedure to search for regions to investigate.

I've been trying to find some spare time to finish constructing a small suite of tools for handling iterated maps in a variety of ways, but it's not in a state ready to share yet. A central issue is in making it automatically as fast as possible, given the quite different supports of evalhf, option hfloat, Compile, and Threads.

@Markiyan Hirnyk Ok, that may be useful, though an optimization (maximization) problem might also do. Convexity has not been shown, but if it were than your fsolve result would be almost enough to show that abs(delta)<0.5 assures that the error term abs( sin(exp(100)+delta) - sin(exp(100)) ) will be less than 0.5.

But still Digits=100 is used without any evidence show why it is enough working precision. Why was 200 not needed? The purpose of part a) is, I believe, to put that aspect on a more firm footing. Which is (I think) the key as to why sin(exp(exp(100))) is so hard to approximate accurately.

@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.