@JAMET Please stop creating duplicate Question threads for this. They get flagged as such and then deleted.

You should explain what your program is supposed to accomplish, in proper detail.

If you only put one long sentence in your Reply's title then that gets elided by this site, and we can't see it all.

Please write a short paragraph in the body of a Reply, and explain what you are trying to accomplish.

If you are trying to get a parametric equation for the line then you could usefully start by explaining where the parameter(s) comes from.

Does it come from the arbitrarily chose point?  Or is the point fixed and the parameter(s) come from the ellipse (which is varying)?

It's not very useful to post only a block of code and expect the code attempt itself to be sel-explanatory.

@nm Your having difficulties with some programming approach, in and of itself, doesn't make the approach an illness.

I changed the tags on this Question to things like assuming and precedence (prior to any Replies or Answers appearing), because that's where your difficulties lie here (ie. not with map per se).

Without proper bracketing, your attempt

   map(X->odetest(X,ode) assuming x>0,[sol])

is not splitting up arguments as you expect.

IMO you should go with choices that you already understand and have no difficulty with, such as,

1) use map with this functional form of calling sequence, and with simple infix syntax for assuming,

    map(odetest,[sol],ode) assuming x>0

or

2) go for the robust and clear separation of `assuming` arguments by using this kind of prefix operator syntax,

   `assuming`([map(odetest,[sol],ode)],[x>0])

If you didn't anticipate or figure out on your own any precedence issues (relative binding strength of assuming, etc) on your own then why go for any bracketed quick-fix alternative solution? The prefix-form call of `assuming` is programatically flexible, clear, robust, and bypasses this given issue (which may otherwise be more likely to trip you again later...).

@janhardo Your followup example's syntax for calling plot3d is not valid.

You may have intended the effect of,

   view=[x_range, y_range, z_range]

which you could use instead of your,

   x = x_range,
   y = y_range,
   z = z_range

@Khair Muhammad Saraz You still haven't provided any worksheet. I doubt it would help, though. It's your project work, not mine.

Yes, I alluded to this aspect of the axes tickmarks before, but I guess you didn't notice: The listcontplot command doesn't provide a mechanism for using custom axes tickmarks or scale. It just uses the dimensions of the Matrix/listlist for tickmarks.

That's why (when I alluded to this before) I also(!) referenced interpolating alternatives and provided links for that. With an interpolating function one can just use contourplot and get tickmarks that match the ranges.

Sorry, I cannot answer any more of your queries. I suggest that you learn how to use Maple enough to do these things for yourself. You could read and understand and use/adapt material in the links provided, for this.

@Aung I did it in stages to try and make it more understandable.

Sure, you can wrap together some of the steps, and bypass inert calls, to make it a bit shorter.

But there is no dedicated command for turning an integral of a sum into a sum of an integral. That's what that particular subsindets call does.

Download 1111_acc.mw

@Dkunb Your procedure proj_wigner is neither assigning nor returning the result of,

   [seq([seq(subs(m=i,n=j,wp),j=1..d2)],i=1..d2)];

to anything. It worked, but no more use was made of it.

You could try, instead,

   w :=  [seq([seq(subs(m=i,n=j,wp),j=1..d2)],i=1..d2)];

and then return w at the end, to see it working.

Also, I recommend using eval instead of subs, unless you have some good reason not to. I.e.,

   w :=  [seq([seq(eval(wp,[m=i,n=j]),j=1..d2)],i=1..d2)];

@Dkunb My point is that the concept of "simpler" here is ambiguous. There's short-and-ugly and larger-with-great-structure-insight-and-symmetry, and a world in between.

Do you want as much combining of trig terms as possible (even if the result is slightly larger?)

Does you want the exp terms in trig form? If so, do you want the terms grouped by trig function or by real and imaginary parts? And so on...

@Khair Muhammad Saraz 

Please attach your worksheet.

Taking nops of a Matrix or a Vector (one of its rows or columns) does not return the number of elements. Your MM is a Matrix. The command for that is numelems, not nops. There are better ways to get the dimensions, IMO.

Perhaps you intended on of these:

listcontplot(MM[..,2..], axes=boxed);

listcontplot(MM[..,2..]^%T, axes=boxed);

listcontplot([seq([seq(MM[i,j],
                       j=2..op([1,2],MM))],
                  i=1..op([1,1],MM))], axes=boxed);

Let me know whether you'd rather do interpolation (linear, spline, cubic) instead, to get smoother curves or nicer axes tickmarks.

@MaPal93 

Regarding your attachment above that balked after 55 iterations (I think maybe it was named fsolve_does_not_work.mw):

Once INDEX gets up to about 0.55 (or 0.554...) some of the solved variables become very large (in a solution). Then you have both small and large values in the "root". In order for fsolve (or you) to establish that it really has obtained a root it performs a residual calculation. But as things get worse the required working precision (Digits) needed to do that accurately gets larger too.

Experiment indicated to me that default Digits=10 was producing bogus results already. Still indicative that solution values might be approaching a singularity. But not accurately. Raising Digits (30, 50, 100...) only brings temporary relief.

Moreover (and I know this sounds facile, but I'm being serious), it can help to pause and try to define the notion of a "root" -- in this float context. Once you have such, you can program for it.

By default the residual check (after resubstitution; forward error) looks to inbound Digits to fsolve for its scale. You can make an end-run around that by using operator-form instead of expressions, for the equations. Such black-box procedures are free to temporarily raise just their own working precision, for just each time they are invoked. This is an end-run around the catch-22 that raising Digits at the higher level -- as a means to evaluate the expressions more carefully at each iteration -- also has the effect of making the residual checks more strict. Using black-box procedures can separate the working precision for the functional evaluations (Digits now set withing the scope of the procedures) from the accuracy requirement in the residual check.

Which of the names I1,I1,alpha,beta,y,d,h,Q1,Q2 are the parameters over which you want to minimize, and which have (some of the) numeric values that you've used?

Note that the objective TR you've used was defined using y = 0.7, d = 2*10^9, h = 35, k = 10^7 and alpha = 0.02*exp(0.4*I1), beta = 0.02*(1 - exp(0.5*I2)).

So why then do you include constraints that only include alpha,beta,y,d,h ?

You also defined TC and TC2 using Q1 = (alpha + beta)*d, Q2 = x*d*h - delta*(alpha + beta)*d*h.

So it's quite unclear what role you intend for your constraints, and what the independent parameters are.

@MaPal93 I don't know that it could be done using the usual substructure generated by the legend item.

Of course, it would also be possible to fake the legend by putting three straight lines in a polygon that is placed carefully in an otherwise blank region of the plots interior. But that kind of ad hoc solution requires effort (locate such a region, make a nice scale, etc.) The up-side is that you can make such lines as long as you'd like within the restrictions of the region.

@Khair Muhammad Saraz To address two more followup queries by you:

For a 2D contour-plot from the Matrix MM you have two choices:
1) Do it directly, using the plots:-listcontplot command.
   (That's easy to do directly, but the axes tickmarks are trickier
    to get to match some arbitrary ranges). Eg,

   plots:-listcontplot(MM[..,2..],tickmarks=[[],[]]);

2) Using Interpolate, and then use plots:-contourplot on that.
  (The first part is trickier, but has also been done before by me on
    this site. There's also an Example worksheet on Interpolation
    and smoothing that illustrates the first part.
    See also,
      Help Topic, ?examples,Interpolation_and_Smoothing
      some old post)

In my Answer's original attachment I already showed you how you could make nice tabulated data from a Matrix like MM.  dq_code_1_acc.mw

@nmacsai The baseline for the color-bar doesn't appear to adjust properly w.r.t. the bottom of the title (in the way that the 3D portion does, say).

It seems that enlarging the view of the COLBAR's contents, along with judicious use of size for both parts, can make a suitable vertical adjustment.

Can_I_change_the_location_of_the_color_bar_caption_in_Maple_2024_sol1_ac1.mw

Unfortunately not all of that was automatically determined. Automatic determination of the adjustment values might be possible, using font height (if obtainable in pixels, which can be an OS thing) and the view-to-plot-region-size ratio.

ps. Combining by plots:-display may well strip off such size adjustments. That's why I did a substitution for COLBAR's elements only after plots:-display.