@Carl Love Great.

So I suppose you could add that to the `ModuleLoad`.

Perhaps the `ModuleApply` could accept anything, and return the first argument if it were not of the new type `RealIntervals`.

@student_md 

The fancy GUI table cannot be converted to LaTeX, though it is possible to generate some lengthy XML. Doing anything with all that in LaTeX would likely be very difficult.

The easiest thing would be just to convert the 2-column Matrix to LaTeX, which produces \begin{array} ... \end{array}. If you needed to you could substitute "tabular" for "array" in the LaTeX string generated.

Below, I strip out the left- and right square brackets.

I notice that the Maple LaTeX command is mis-treating floats, when handling the Matrix. So it turns 1.2345e-11 into 0.000000000012345 which is not nice. So I'll include some patch-ups involving float notations. (Goodness, it'd probably be easier to write a better Matrix-to-LaTeX export from scratch. Oh well.)

Download student_md_question_2_acc.mw

@Carl Love Vote up.

I think that the extension mechanism requires an actual procedure, which can be wrapped around an appliable module. (It's also possible that you tried that as a second attempt, but neglected to clear the remembered result.)

Download simplify_intervals.mw

How about uploading a worksheet that let's us explicitly see (or experiment with) your example?

@Spirithaunter After making the replacements I suggested throughout I no longer see that error message at all.

Spirithaunter_01.mw

Please upload a worksheet that reproduces the problem.

@vv I tried to give the OP some advice about not using unapply (and a procedure call) when an expression would serve. That is enough to avoid the problem.

But the originally exhibited problem is deeper, I think. In the examples below, what is the essential difference between Vectors boo and rah? Why does mapping eval across rah have such an effect, while applying rtable_eval (to rah, or V, or anything in sight, with or without its inplace option) does not have a similar effect?

I agree with you that the construction was unusual. It seems like advice might include: don't unapply a Vector and then subsequently change that Vector's entries.

Download Vector_unapply_oddity.mw

@student_md Suppose you have an expression already, involving the global name t. And then you construct a procedure (operaotr) using just the arrow notation directly. The parameter t of the procedure (operator) is different from the global name t inside the expression. They look the same, but they are quite distinct. When the procedure is called it uses the value of it argument wherever that name is used in the body of the procedure. But in the following example the parameter t does not occur in the expression (since that contains just the global name t).

restart;

expr := t^2;

                        2
               expr := t 

p := t -> expr;

            p := t -> expr

p(2.1);

                    2
                   t 

This is a frequently asked question. Here are some ways to make it work. Note that :-t is a useful syntax for referring to the global name t, and distinguish it from a parameter or local name t.

expr := t^2;

                            2
                   expr := t 

r := unapply(expr, t);

                             2
                  r := t -> t 

r(2.1);

                      4.41

s := subs(dummy = expr, t->dummy);

                              2
                   s := t -> t 

s(2.1);

                      4.41

w := t -> eval(expr, :-t = t);

          w := t -> eval(expr, :-t = t)

w(2.1);

                      4.41

As you can see, unapply provides one convenient way to construct a procedure from an expression.

Try not to overuse unapply. It can be inefficient to have a procedure F that calls unapply each time you call F. Another way is to use 2-argument eval to evaluate an expression at a value for a name. Eg,

expr := sin(x)*exp(x):
eval(expr, x=2.1);
                                 7.049114358

Also, never bother to create a procedure with unapply if you're only going to just call it with a name for its argument. You may as well just use the expression. Eg, here's something I see now and then,

restart;
expr := sin(x)*exp(x):

f := unapply(expr, x):
plot(f(x), x=0..Pi);   # this is silly, if it's the only time f is used.

plot(expr, x=0..Pi);   # one could just as easily do this

Also, don't try and use a function call on the left-hand-side of an assignment statement, unless you really know what you're doing. That was part of your original difficulty in your Question. That's complicated.

And so you could avoid the original problem simply by following the advice to not create a procedure (with some parameter name) and then only use it with a function call to the same unassigned name, or the advice to not assign to a function call.

This adjustment makes it almost identical to my answer.

restart;
C :=[[0,1/11],[1/11,1/9],[1/9, 1/7],[1/3,1/2],[1/2,1]]:
C1:=map(t->x>=t[1] and x<=t[2], C):
op(map(`[]`@op,[solve(`or`(C1[]))]));

               [0, 1/7], [1/3, 1]

@student_md Yes, the MatrixSystem is not linear in the c[i] so it makes no sense to try and use GenerateMatrix (let alone linsolve or LinearSolve).

Even if it were linear for another example, its a mistake to re-assign to lowercase b since that's being used for the x-range lower endpoint.

ps. Did you edit the original Question and remove material?

I see that Kitonum already gave essentially the same answer, while I was still typing. The only difference being that I converted the RealRange results from solve into lists (just to match the OP's input of a sequence of lists).

Note: RealRange can prettyprint like a list. I don't know whether the OP prefers lists, or is not aware of the RealRange structure.

So, another variation, if say we started with a sequence of RealRange rather than a sequence of lists.

restart;

C :=map(RealRange@op,[[0,1/11],[1/11,1/9],[1/9, 1/7],[1/3,1/2],[1/2,1]])[];

                 /   1 \           /1   1\           /1  1\  
   C := RealRange|0, --|, RealRange|--, -|, RealRange|-, -|, 
                 \   11/           \11  9/           \9  7/  

              /1  1\           /1   \
     RealRange|-, -|, RealRange|-, 1|
              \3  2/           \2   /

solve(Or(op(map(r->convert(__dum::r,relation),[C]))));

                         /   1\           /1   \
                RealRange|0, -|, RealRange|-, 1|
                         \   7/           \3   /

@student_md Obtaining the min and max depends on the kind of plot, yes.

If you upload an example with a different kind of plot or coloring scheme then we can show you how its data can be handled to get a corresponding colorbar.

@minhthien2016 I edited my Answer to illustrate that.

I suggest that you tell us what shading/coloring scheme you want to accomplish.

For example, would you be content with shading by hue, as the (z-value) height changed?  Eg,

num_sol:-plot3d(x=0..1, t=0..1, shading=zhue, grid=[79,179], style=surface);

num_sol:-plot3d(x=0..1, t=0..15, shading=zhue, grid=[79,879], style=surface);

And here is a variant where the burden is not on the user to specify the z-height contour values up front.

I consider that as a useful case. It's never quite satisfying when a nifty use of contour plots requires the user to figure out in advance what contour values to use. It's nice that we can force the values, but many users will prefer the system try and do it.

I've been wanting this for some time, and realized that I can now get it easily by ripping it out of the hover-over contour label substructures that plots:-contourplot now produces. (It's a little weird that I didn't think of this earlier, as I've used the info in those new substructures for other cool things.) I've never liked the idea of averaging the values obtained by substituting CURVE x-y data points into the formula.

And the contours on the upper 3D surface are rendered by the GUI from the CONTOURS substructure rather than from CURVE substructures (which very often look jagged and either too thick or too thin, alongside a surface).

In summary: the precise contour values are the same for the 2D density + contour plot as they are in both 3D surfaces. And the color shading is also exactly the same.

These plots look much better in the actual Maple GUI than they do when rendered inline by this site's backend.

Download 2d_3d_filled_contours.mw