@Ronan The structure of my type-check was as follows:

  type(...,
            And(                            # it must pass all the following
                      name,                # it must be of type name
                      Not(constant)   # disallow Pi, gamma, etc
                      satisfies(mine)  # return true when mine is applied to it
                    )
         ) 

Here's some explanation of my use of type satisfies. This type allows you to utilize a custom procedure as the predicate of the type-check. That's very flexible and powerful.

Download type_satisfies.mw

@C_R Were you trying something like the following?

(evalc takes the unknown a as real)

(we can optionally simplify the signum(a)^3 to just signum(a), for a little extra clarity)

Download C_R_polar0.mw

@MaPal93 

I mean,

  max( 0, min( 10, Z(X,Y) ) )

That makes only the range 0..10 be used for applying your shading scheme. You get to see actual green even if Z(X,Y) would produce a huge value otherwise for some X,Y in domain.

It can also fix the flashing that the GUI can have when rotating 3d plots in such situations of massive out-of-view values.

Also,

  view=[default,default,0-1e-5 .. 10+1e-5]

(or, keep original view and adjust added max/min cutoffs accordingly by small amount)

if necessary due to possibility of introduced flat artefact.

In the following example, the first surface doesn't actually show any green portion.

plot3d( 1/(100*(x-3)*(y-2)),
        x=2..3, y=1..2,
        'colorscheme'=["zgradient",["LightGray", "Gray", "Green"]],
        view = 0..10);

plot3d( max( 0, min( 10, 1/(100*(x-3)*(y-2)) ) ),
        x=2..3, y=1..2,
        'colorscheme'=["zgradient",["LightGray", "Gray", "Green"]]);

@C_R You can also write an extension to convert, which pulls the argument (arg) out front of a usual polar cal, if that is what you'd prefer.

With a polar call it can be further used, as usual.

Here's that convert-extension idea, and then using it alongside the print-extension from my Answer.

Also, this makes the "e" appear in upright roman, like the usual `exp` pretty-printing. (Other names pretty-print in italics.)

This "e" also pretty-prints in purple, as a visual cue, which I personally like since the underneath it's a `polar` call. Remove if you'd prefer.

Download convertPolar.mw

You can also add your content-menu items, you know. Do you want one for converting a complex number to such a form?

One could also use the inert representation from my Answer to construct a custom print-extension for polar.

In the following worksheet the returns are all still just polar(...) calls, underneath, and evalc et. al. work on them as usual. They just happen to display in 2D Ouput as the OP has asked.

Download printslashpolar.mw

Personally I would never do this for usual Maple work. It's be unnecessarily confusing, because it's not WYSIWYG. There is no visual cue that the typeset output is not as it appears. Maybe if it were in purple...

@C_R No, it's not "automatic simplification" in the sense of the Maple manuals, that'd get in your way here and would undo the direct attempt. It's just usual evaluation.

Enter exp(I*Pi) and hit return and the evaluated result is -1.

So you can avoid that evaluation by using some kind of inert representation.

1) 'exp(I*Pi)' with single right-ticks in only good ephemerally. Any subsequent full evaluation undoes it. Assigning to a name foo and only passing it around as eval(foo,1) is quite awkward. (Btw, this shows that automatic simplication is not the problem.)
2) Some hack like exp(``(I*Pi)) is often ugly. Extra bracketing as output, extra op calls to manipulate, etc. ugh.
3) This is the kind of thing and inert operations (beginning with %) are designed for; a useful way to prevent evaluation while still being able to programmatically manipulate expressions in some usual ways. If you want you could also construct it (in 1D) as %exp(I %* Pi) .

Of course you could also start off with exp(i*Pi) and then eval(..,i=I) when you wanted. Seems clunkier to me. Or something weird with, say, i:=I: followed by local I: then eval the other way. Also clunkier, IMO.

You could easily write an app in embedded components, or just nifty commands, to demonstrate all this to students. But, then, you could easily write apps to do an untold number of different things.

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