@Pascal4QM  You have missed the point entirely. The OP wants 2D Math inlined (amongst text) that is unexecuted, rather than unevaluated.

You have shown something about inert calls, which act as if unevaluated. That is not at all the same as unexecuted.

@mugwort I don't understand what you're trying to say about its not accepting strings. The tickmarks can be strings.

You can easily make the tickmarks be strings. Just uses a sequence of equations, where the LHS of each is the position/value and the RHS is the tickmark to utilize. There are examples like this on the Help page for topic plot,tickmark 

For example,

[seq(i=sprintf("uu[%a]vv",i), i=1..10, 3)];

     [1 = "uu[1]vv", 4 = "uu[4]vv", 7 = "uu[7]vv", 10 = "uu[10]vv"]

plot(x, x=0..10,
     axis[1]=[tickmarks=[seq(i=sprintf("uu[%a]vv",i),
                             i=1..10, 3)]]);

To follow up on what Carl has written, the accuracy of individual elementary operations with floats should be accurate to with 0.6 ulps.

But that still allows for roundoff error to accrue within compound operations.

The enterprising person can write a reusable front-end procedure to use shake/evalr as Carl has shown. (I called mine `feval` and tried to give it proper emulation of 2-argument eval-at-a-point.) There are rare circumstances in which additional guard digits are required to be used for even shake to not be misled.

The difference in models of floating-point computation is (IMO) one of the most important differences between Maple and Mathematica. The latter uses its own proprietary (and undisclosed) interval arithmetic style scheme to attain target accuracy all round. Wolfram claims it works throughout, but examination of their user forums can reveal examples where it produces inaccurate/wrong results.

The majority of programming languages suitable for scientific computation behave more like Maple (which claims to conform to IEEE 754/854). Although of course most do not support arbitrary precision floats.

In my Maple 2019 (and at least back to Maple 2016) I can use Shift-F5 to get into the mode where input is in 2D Math that does not execute.

And I can toggle between these input modes.

Shift-F5   (non-executable 2D Math, or toggle)

Ctl-r   (executable 2D Math)

Ctl-t    (plain text)

Is E supposed to denote the ellipsoid from your earlier question?

Please don't ask the same question more than once.

Put your followup details here, instead of in a new thread.

I just want to make sure that I get it straight what your issue is.

Is the following summary correct? In your Maple 2019,
 - You switch between text and inactive inline 2D Math and back again using Ctl-F5 and Ctl-t, and that part works fine.
 - When you copy and paste such a block of text (that contains inactive inline 2D Math) then all of the inline 2D Math becomes active and executes when you do hit the !!! icon, etc. And that, of course, would not be fine.

If that second bullet point is the essence of your problem then, sorry, I don't of a setting that will make Copy&Paste directly respect the "activeness" of the 2D Math blocks inlined in text paragraphs.

@mmcdara I agree that it is difficult because there is little to no documentation of the so-called TypeMK used for rendering 2D Math.

It is somewhat similar to what gets constructed by calls to Typesetting:-Typeset, the major difference being that it is a specially marked up single name rather than a nested function call. For example,

Download TypeMK_ex.mw

As for HTML and unicode entities within typeset stuff, here is an example. Note that the unicode representation can be in the decimal or hex format, where the distinction is accompanied by the extra x symbol. I usually do a web search when I forget an entity name. (Eg, this)

Download entity_unicode_typeset.mw

@mmcdara I may well not understand properly what kind of characters you want, and where, but perhaps this will give you some ideas. 

I wasn't sure if you wanted to replace the symbol "ID" used at a vertex, or place something at that level, etc.

Note that plots:-textplot allows the supposed text to be supplied as typeset(some_seq) where some_seq can be an expression sequence containing "\n" entries. And you can use entities in the other entries of such a sequence to be typeset.

NAC_ac.mw

@mmcdara I'm curious about your need that made you turn to image drawing facilities to modify/construct your rendered graphs (in the Graph theory sense).

The results from DrawGraph look much better than they used to. But I'd agree that there is room for improvement.

One way to get typeset Greek letters or other entities on the vertices of a drawn Graph is by using normal alphabetic characters in the Graph passed to DrawGraph and then substitution into the resulting PLOT structure. Eg, using a variety of ways (HTML entities, straight Greel letter name, unicode),

Download graph_entity1.mw

Or did your goal also include a customized look for the arrows designating a directed Graph, eg. something like this where the edge is depicted with a stretched arrow entity?

I understand, if you've already got a working mechanism for doing any or all of that via drawing and images. I was just curious about the main obstacles you faced.

@mmcdara I do not always mention it when I submit a bug report against an issue I find while investigating a Question in this forum.

I mentioned here to convey also that I considered this example a weakness in simplify, since the Question and my Answer were more about how to apply commands to each entry of the Matrix. (The OP seemed to have already found an adequate command, but wanted to apply it throughout, I believe.)

I considered the example something that simplify might reasonably be expected to handle itself (ie. the trig arguments are not large integers, and expand doesn't blow the individual trig calls up to huge expressions.)

Bug reports generally help.

The simplify command is being improved in at least some ways. Consider this basic example, which produces zero in Maple 2019,

restart;
ff := cosh(z) + sinh(z):
simplify( exp(z) - ff );
                          0

@michalkvasnicka On what grounds do you make this strong claim?

Could you give your example?

Additional details that might be relevant include: Maple version, Operating system, Maple language pack (if any).

In case anyone's interested, I'm submitting a bug report about this weakness in simplify ,

restart;

ee := cos(omega*t + alpha)/2
      - cos(omega*t + alpha + Pi/3)/2
      - sin(omega*t + alpha + Pi/6)/2:

expand(ee);
                               0

lprint( simplify(ee) );
  1/2*cos(omega*t+alpha)-1/2*cos(omega*t+alpha+1/3*Pi)-1/2*sin(omega*t+alpha+1/6*Pi)

lprint( simplify(ee, trig) );
  1/2*cos(omega*t+alpha)-1/2*cos(omega*t+alpha+1/3*Pi)-1/2*sin(omega*t+alpha+1/6*Pi)

@nm The scenario you describe -- with nested calls to commands without proper regard for what they might return and a reasonable chance of a mistaken call -- sounds to me like inadequate type checking, parameter checking, and quality of programming on the user's part.