21438 Reputation

29 Badges

15 years, 115 days

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by acer

@ebrahimina I much prefer to have multiplication show explicitly, even in 2D Input. Relying on a space to denote multiplication implicitly often leads to confusion and mistakes. But in this case the * appeared when I copied and pasted, I suspect. [edit] I have revised my Answer to use the unitless range 0..100 since the calls to tau and Q already contain argument x*Unit(mm). [/edit]

Did you have a second followup question?

On the topic of style, I also dislike using the syntax Q(x):=...  to denote assignment of an operator, but I forgot to change it when replying. That syntax is ambiguous and can also be used to denote assignment to the remember table of Q. And ambiguous syntax is error prone. I much prefer the syntax Q:=x->... 

By the way, I used Maple 2017.2 in my Answer, since the OP's original attachment was last saved in Maple 2017. I also tried to write the answer so that the OP could use his original definitions of Q and tau, as is, and call plot without having to strip or cancel out the units.

Start by giving us proper details.

Stop spamming this site with your homework questions.

Put all your homework assignment questions into a single Question thread, if you really can't be bothered to learn basic Maple syntax or work out even the simplest problems yourself.


@mmcdara Using Maple 2016.2 so as to get Statistics:-HeatMap, here is some overlaid colored mixes of plaintext and 2D Math.

It uses a procedure that colorizes or enboldens typeset representation of math expressions or strings.


I've written such a procedure several times over the years. I agree with you that it can be useful. Let me know if it requires tweaking. I think I wrote this particular one so as to get mixed colored captions on plots.

On the help page for DocumentTools:-Tabulate the first sentence in the paragraph where it describes the color option says, "The foreground color for text."

I interpret "text" as meaning entries which are strings and not expressions. Which means that the behavior is just as documented. Not a bug.

It would be nice to also have control over typeset 2D Math, as a functionality enhancement. One possible scenario would involve the existing color option also affect typeset math, with an additional option (say, typesetcolor) which could override that.

@DisabledWhale That 2D Input syntax for operator assignment that you are trying to use is highly ill-advised.

I have suggested several alternatives which work properly and make sense in the Maple programming language. Those alternatives work in both 1D and 2D input mode. They do not use ambiguous syntax. They do not rely on settings in the GUI or worksheet, and as such will work the same if re-run later by you or others.

The 2D Input syntax for operator assignment that you are trying to use, has several significant problems. It is ambiguous and clashes with remember table assignment, and in 2D mode you or anyone else cannot immediately discern which meaning is there. That 2D syntax is not universally the same in all recent versions of Maple. You or others may well have problems figuring out at a later date what you intended. The syntax that you are trying to use has a history of causing problems, is difficult to figure out, has been implemented suboptimally, and is implemented inconsistently across versions.

But you want to use that particular 2D Input syntax for operator assignment anyway. It's not that I don't want to help you with that, but rather that I am unable to properly help you with that. Nobody can properly help you with that because it is generally unworkable, so even if you figure out this particular question it will give you problems later.

@jmalik7 That agrees with what I wrote before.

Your approach has at least one mistake, since you define W using symbol w before you place assumptions on w[i,j], and more importantly because you have no assumptions of, say, realness of the y[i,j].

But if set up more suitably then I suspect that you may receive a result of FAIL from is, which doesn't help. Even this happens, it seems:

is((y22 - y12)^2>=0) assuming real;

is((y22 - y12)^2+b>=0) assuming b>=0, real;

is((y22 - y12)^2  + (y21 - y11)^2>=0) assuming real;

So even if you simplify as follows it may be that is has issues dealing with it.

K := simplify(Trace(simplify(Transpose(Y) . (d-W) . Y))):

collect(K,[w[1, 2],w[1, 3],w[2, 3]],Student:-Precalculus:-CompleteSquare);

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

First 78 79 80 81 82 83 84 Last Page 80 of 450