@janhardo If I add it with the `true` as last argument to AddMet then it does get used and work. See the verbose printout. Of course I commented out the test-line to remove it, after adding it.

But your BestSimp routine is not returning the result with shortest value (LeafCount metric). I leave that for you.

fullSimplify_module_-metoden_toevoegen_werkt_ws_uitzoeken_forum_opmerkingen_corrigeren_A_acc.mw

@janhardo If you assign,

   fn := eval(parse(cat("proc(e) ", method_body, "; end proc")));

then (since procedures have last name evaluation) you'd want something more effective like,

   methods[method_name] := eval(fn);

instead of your,

   methods[method_name] := fn;

in order to add it more usefully to the table.

I am not a fan of passing/parsing a string, but here is that last worksheet, edited:
fullSimplify_module_-metoden_toevoegen_werkt_ws_uitzoeken_forum_opmerkingen_corrigeren_A_ac.mw

@janhardo You have the table `methods` as a local of BestSimp, which makes no sense, since you're trying to access/amend that from other procedures in the parent module of BestSimp.

Your code for a test/check (that it has worked properly) is also faulty.

Using globals in the other procs isn't the way to fix that. Using globals is also very poor programming for this (even if you altered the code to use it consistently). You have already got a module; you should utilize that fact, with a Record or table.

You don't need to inline the whole attachment here, each time.

@janhardo I don't see an attachment with a list named methoden, and so it's not clear what "worksheet" you're now referring to.

I see a table named methods in the module in your last attachment, a worksheet named,
   Module_fullSimplify-2_commands_MPforum.mw
but the paremeters of that module's export AddMet does not match your subsequent query about calling it like,
   AddMethod("TEST(e,trig)", proc(e) return TEST(e,trig); end proc);

Look again at your Reply in which you asked about this. It has no worksheet attachment. All it contains is the following -- which is why I responded using its very same format of arguments:

How to get the TEST methode name into the list methoden ?
The methoden list has more names in it.

AddMethod("TEST(e,trig)", proc(e) return TEST(e,trig); end proc);


methoden := [
        "CompleteSquareSteps(e)" = proc(e) return CompleteSquareSteps(e); end proc,
        "TEST(e,trig)", proc(e) return TEST(e,trig); end proc
          ];

@janhardo That's what my first block of code shows. I leave it to you to incorporate it into your own module.

note: You mentioned a worksheet containing `methoden`, but never gave it.

@janhardo An example,

Download module_ex.mw

@SUN ZHUOYU 

A few comments, if I may:

1) If your connection is poor then you could remove all output from the worksheet (see menubar) which in this case makes the file much smaller.
2) I also changed how points1 is created (using the last way in my original Answer above), and made some Matrices more directly.
3) Your workseet uses B:=100 to set up the data, and then clobbers that by making B a Matrix. That means you cannot go back to some earlier stages of the code without needing a restart. (One of your screeenshot images looks like you made such a mistake at one time.) It'd be easier if you simply used different/distinct  names for different purposes.
4) the final call to display was misspelled as "dispaly" which is why it didn't produce&render a final plot.

@SUN ZHUOYU The command listplot3d doesn't have dedicated options for specifying the ranges over which the x- and y-axis data are be interpreted.

But the surfdata command offers that.

3D_exact_and_numerical_solution_comparison_ac.mw

@SUN ZHUOYU I'm not going to look at your followup (or any other Question of yours) if you don't upload and attach your actual worksheets.

It is poor etiquette to expect people to manually enter equivalent code based on mere images and screenshots.

More importantly, your image appears to be an incomplete picture of what was going on. It's not clear what is your actual problem or goal.

At the top of your image, what are x[j] and y1[j] supposed to reference? Is it top secret? If you're trying to programmatically construct points1 then show us the complete original worksheets.

@Andiguys Regarding your followup G1.mw worksheet, your constraint C1 requires that Q2 be at least 9.2e7 for sigma=0..3.

There is no possible feasible sigma,Q2 pair satisfying C1, given your ranges sigma=0..3 and Q2=4.0e5..2e7.

ps. The minimum of TRC(sigma,Q2) for sigma=0..3 would occur at sigma=3 and Q2=9.27e7.

pps. You should construct TRC by,
    TRC := unapply(eval(TC1c, DATA),sigma,Q2);
instead of just unapply(...,sigma), so that you can properly call TRC at a pair of values, to check.

You might find using implicitplot useful. (...which I also did here -- extruded to 3D barrier surfaces -- in earlier answers for an earlier model variant you'd posed. You could also do that here.) This followup is not complicated, but if you have trouble understanding it then plots could only help.

G1_ac.mw

Now, could you explain your difficulty in understanding, when constraint C1 is removed? You have sigma=0..3, and if sigma is not negative then the smallest sigma possible in that range (ie. sigma=0) will attain at the minimum of TRC(sigma,Q2) which is given by,
   1.22675e9 + 2.5*Q2 + 3.8e7*sigma
   +700000000*sigma*(0.02 + 2.285714286e-2*sigma)
and Q3 doesn't preclude sigma=0 for your Q2>=4e5.  Notice that sigma only appears in terms of the sum TRC(sigma,Q2) which each consist of positive coefficients multiplied by mere positive-integer powers of sigma. Without hampering by constraints that sum is clearly minimized over sigma=0..3 at sigma=0.

@JAMET Your code has,

   180 - 180*arctan(alpha)/Pi

instead of,

    180 - 180*alpha/Pi

But the arctan step was already done earlier in your code.

@sand15 I though it might be fun to see how large n could be while obtaining an exact result.

@sand15 How tight are cons_1, at different n? Are they always equality?

Please do not spam other old threads on this forum with duplicates of your request.

There are more edits you could do, but here is a start. I've deliberately left the bulk of your procedure as it is, since that's your (evolving) style.

I used an appliable module, with the helper procs, shortened some calls utilizing the uses stuff, adjusted the textplot alignments a bit, and adjusted some rounding evalf stuff, and allowed extra arguments to triangle be passed to the final plots:-display via _rest.

Download SEC_ac1.mw

nb. Never do evalf[4](...) or evalf(...,4) of a complicated formula., even if it exactly/symbolically represents some constant value. However It's OK to use such a call on an already-computed float value, to get final rounding effects. But you don't want to accidentally make the whole float computation be done at low working precision. If you accidentally do it on a formula then it only uses 4 digits of working precision and that will often lead to a rubbish result due to numeric roundoff, loss-of-precision, catastrophic cancellation, etc. Here are two ways to go wrong, and two ways to get it better:

Download dig_ex.mw