What have you done so far, for this homework question?

@Carl Love That's right, on all counts. But I have a hazy idea that issuing gc() explicitly may not always force a garbage-collection in modern versions the way it did some years back. I suspect that sometimes it does it when it wants to.

I suppose that, with enough calls to a Matrix initializer it might be quicker to Compile after burning the N parameter into the proc template. But that may be academic as far as optimality goes, since an in-place single procedure could walk a preformed empty Matrix and be compiled.

I left the extra procedure layer since then it had the same construction mechanism as the routine I wrote. But I was just curious about a different short way to generate the values from the indices. I have doubts that I proved much, performance-wise.

@gawati2611 Here another variant on a procedure which generates the entry value from an index pair.

Q:=proc(r::integer,c::integer,N::integer)
  local d::integer,t::integer;
  d:=c+r-2; t:=iquo(d*(d+1),2);
  `if`(d<N, t+`if`(d::even,c,r), N*(2*(d+1)-N)-t+1-`if`(d::even,r,c));
end proc:


# For example, second row for size N=6
seq(Q(2,j,6),j=1..6);
               3, 5, 8, 14, 17, 26

Matrix(3,(i,j)->Q(i,j,3));
                  [1  2  6]
                  [3  5  7]
                  [4  8  9]

And here is a worksheet, for fun.

[edit] Don't take the timings too seriously. If you wanted better performance for the Matrix construction then I expect that you could Compile a decent procedure which walked the entries of the Matrix in bands using loops, and acted in-place (thus avoiding overhead of calling a Matrix initializer procedure on each entry).

Download mattrav_ac3.mw

@Thomas Dean Yes, it is strange indeed that you would not mention at the beginning that it was for a specific x value.

@nm Your interpretation of what is going on is not correct.

If you do the parse without the eval (or statement option, which induces an evaluation) then the variable ode is assigned the unevaluated expression. That happens whether done at the top-level or inside a procedure while assigning to a local name. What gets assigned to name ode is the same in both cases.

What makes a difference is the degree of evaluation when that assigned name ode is subsequently passed as argument to another procedure -- such as dsolve. In the top-level case it is evaluated, and in the procedure local case it is not.

The difference is in how the assigned name ode is subsequently evaluated (or not) when passed around. Contrary to what you suggested, the difference is not the degree of evaluation during the assignment to the name ode.

The 1-level of locals within a procedure is clearly documented on the Help page for Topic procedure.

What is incorrect is your surmise, "...semantics of assignment to local variable is different than assignment to the variable when in global context". The difference is not in the assignment to the local name, but in how it gets subsequently evaluated when referenced/passed.

Download parse_example2.mw

Which side buttons do you mean, left (palettes) or right (context-menu)?

Does it improve if you close the left panel and the right panel?

@AHSAN At lower working precision the floating-point evaluation of the expression (at different values of lambda) might suffer from roundoff error and inaccurate results might get be produced.

Presumably your expression is as you intended it.

You have asked about other rootfinding methods before (and been answered!). I see no reason to encourage you in such duplication of questioning, or to reinvent the wheel.

You are free to utilize your own numeric root-finding algorithms, and you might find the range lambda=0.4..0.85 helpful.

If I'm not mistaken, the original product expression P has -- as one of its multiplicands -- a 5th degree polynomial,
   57441.45187*lambda^5 - 174030.6883*lambda^4 + 209711.5508*lambda^3
   - 125674.0589*lambda^2 + 37467.33188*lambda - 4446.983589
which may be factored approximately to obtain this factor:
   lambda - 0.4632186949799427

@Jak So just use the red curve(s), and not the blue curve(s).

The red is for eq1=0, and the blue is for eq2=0.

They already (each) have a line style (dash, solid) that changes when eq1<eq2 or not.

I threw both the red and the blue. It is trivial to exclude either in the code I gave.

You can also restrict to any particular quadrant -- just specify the ranges and/or view.

For example, also using an alternate approach with an explicit solve, instead of an implicit plot, for eq1=0. You may wish to treat x[u]=0 specially, or exclude it, say with the view. I used a style dot instead of dash. Adjust as desired.

Download eq1eq2_rev2.mw

@Jak I don't understand what you're saying, sorry.

In what I showed the red curve denotes eq1=0 and the blue curve denotes eq2=0, and their linestyle is solid when eq1<eq2 and dashed otherwise.

Could you explain more explicitly how that is not what you requested?

Is it just that you want the two linestyles reversed in purpose? That's a simple edit to the code I gave -- by just switching the instances of the linestyle override. eq1eq2_rev.mw 

Such a flip produces these:

The cube of the rhs of the first equation is not equal to the rhs of the second equation, so are you sure that you have transcribed it correctly?

You had them as,

  y = (sqrt(x) + 10)^(1/3) - (sqrt(x) - 10)^(1/3);

and

  y^3 = 20 - 3*(x - 100)^(2/3);

[edit] As member vv has observed, you may have written down the second equation wrongly, and intended to have written it instead as,

   y^3 = 20 - 3*(x - 100)^(1/3)*y;

Have you considered uploading and attaching a worksheet that reproduces your problem?

Attach the original document that contains all the relevant definitions (i(t), delta, sol4, and so on).

@gawati2611 Your example was exp(w*x*I) and you stated that x and w should be real-valued, and that you'd want the height to be taken as the modulus.

abs(exp(w*x*I)) assuming x::real, w::real;
                 1

evalc(abs(exp(w*x*I)));
                 1

(I mentioned this earlier, in my original Comment, for the very reason that I wanted to check with you that you understood this.)

You could contact Maplesoft Technical Support about this.

The OP also asked about floating-point error and using the Optimization package.

There is no general facility in that package for estimating quantity of the floating-point error, but there are options for controlling (bounding it). Depending on the method, there are options for specifying a tolerance for optimaility of the objective as well as a tolerance for maximal, absolute constraint violation. (See the Help pages.)

Apart from specifying those tolerances, you can also get additional printing of what value gets used for them (either specified, or as defaults).

Note that actual results may be more accurate (ie. smaller error) than the tolerance -- which is meant to serve as a bound, not an estimate.

Note that additional working precision (Digits) may be required in order to ensure that the tolerances are not met accidentally (wrongly) due to numeric round-off error.

Note that there may be a hard limit (16?) on the number of major iterations for some methods.

Download Opt_userinfo.mw