acer

32333 Reputation

29 Badges

19 years, 326 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

Yes, this is handled in Maple 2017 via new Typesetting:-Settings(typesetdot) functionality.

See the second bullet point of the first section of the help page with topic updates,Maple2017,compatibility .

restart

kernelopts(version)

`Maple 2017.2, X86 64 LINUX, Jul 19 2017, Build ID 1247392`

interface(typesetting = extended)

fun1 := diff(x(t), t, t)+2*xi*(diff(x(t), t))+omega[n]*x(t) = a*omega[f]^2*y(t)

diff(diff(x(t), t), t)+2*xi*(diff(x(t), t))+omega[n]*x(t) = a*omega[f]^2*y(t)

Typesetting:-Settings(typesetdot = true)

fun1

diff(diff(x(t), t), t)+2*xi*(diff(x(t), t))+omega[n]*x(t) = a*omega[f]^2*y(t)

``

 

Download dotfun.mw

It looks like you may have inadvertently entered one of those r-subscript-i instances as r__i instead of r[i] , in that call to `seq`.

Make sure that those subscripts are with square bracket indexing and not with double underscores. Otherwise they won't be mutable with respect to index `i` as it takes on takes from 1 to 8.

Also make sure that all the others are like r[1] , r[2] , etc.

In other words, you need to be consistent.

The alternative is to use double underscore subscripting for all 8, and then build the pair inside `seq` dynamically with concatenation. That would be ugly code.

For the example with HankelH1(0,...), without the change of variables. And a few observations about handling the imaginary part.

restart;

kernelopts(version);

`Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877`

ig:=cos(alpha*s)*(1/8*I)*(-HankelH1(0, beta*s)-(2*I)*BesselK(0, beta*s)/Pi)/beta^2;

((1/8)*I)*cos(alpha*s)*(-HankelH1(0, beta*s)-(2*I)*BesselK(0, beta*s)/Pi)/beta^2

bah:=int(ig, s=0..infinity); # Bah.

(1/8)/(beta^3*((alpha^2+beta^2)/beta^2)^(1/2))

evalf(eval([bah, Int(ig,s=0..infinity)], [alpha=1,beta=3/2]));

[0.3081667755e-1, 0.3081667757e-1-0.4969039950e-1*I]

newig:=convert(ig,Bessel);

((1/8)*I)*cos(alpha*s)*(-BesselJ(0, beta*s)-I*BesselY(0, beta*s)-(2*I)*BesselK(0, beta*s)/Pi)/beta^2

conds:=s>0, alpha>0, beta>0, seq(r::real,r=indets(newig,specfunc({BesselJ,BesselY,BesselK})));

0 < s, 0 < alpha, 0 < beta, (BesselJ(0, beta*s))::real, (BesselK(0, beta*s))::real, (BesselY(0, beta*s))::real

ans:=int(newig,s=0..infinity) assuming conds;

(1/2)*2^(1/2)*Pi^(1/2)*(-((1/8)*I)*2^(1/2)*Heaviside(beta-alpha)/(Pi^(1/2)*(-alpha^2+beta^2)^(1/2)*beta^2)-(1/8)*2^(1/2)*Heaviside(-beta+alpha)/(Pi^(1/2)*(alpha^2-beta^2)^(1/2)*beta^2)+(1/8)*2^(1/2)/(Pi^(1/2)*(alpha^2+beta^2)^(1/2)*beta^2))

rans:=radnormal(convert(ans,piecewise,alpha)) assuming alpha>0, beta>0;

rans := piecewise(alpha < beta, -(I*sqrt(alpha^2+beta^2)-sqrt(-alpha^2+beta^2))/(8*sqrt(alpha^2+beta^2)*beta^2*sqrt(-alpha^2+beta^2)), alpha = beta, ((undefined*I)*sqrt(alpha^2+beta^2)*sqrt(alpha^2-beta^2)-undefined*sqrt(alpha^2+beta^2)*sqrt(-alpha^2+beta^2)+sqrt(-alpha^2+beta^2)*sqrt(alpha^2-beta^2))/(8*sqrt(alpha^2+beta^2)*beta^2*sqrt(-alpha^2+beta^2)*sqrt(alpha^2-beta^2)), beta < alpha, (sqrt(alpha^2-beta^2)-sqrt(alpha^2+beta^2))/(8*sqrt(alpha^2+beta^2)*beta^2*sqrt(alpha^2-beta^2)))

evalf(eval([ans,rans,Int(ig,s=0..infinity)], [alpha=1,beta=3/2]));

[0.3081667754e-1-0.4969039945e-1*I, 0.3081667754e-1-0.4969039949e-1*I, 0.3081667757e-1-0.4969039950e-1*I]

evalf(eval([ans,rans,Int(ig,s=0..infinity)], [alpha=2,beta=3/2]));

[-0.1977383032e-1, -0.1977383033e-1, -0.1977383033e-1+0.6e-13*I]

plots:-display(
    plot3d([Re,Im](rans),alpha=0..beta,beta=0..2, view=-1..1, color=[red,blue], style=surface),
    plot3d([Re,Im](rans),alpha=beta..2,beta=0..2, view=-1..1, color=[red,blue], style=surface)
);

 

I suspect that the following relates to how it can lose the imaginary part.

 

ig_hmm:=simplify(Im(newig)) assuming conds;

-(1/8)*cos(alpha*s)*BesselJ(0, beta*s)/beta^2

int(ig_hmm, s=0..infinity); # Bah. We are lucky this didn't happen for `ans` above!

0

 

We can look at similar ways to get it right, or wrong...

 

another:=evalc(Re(newig)+Im(newig)*I) assuming conds;

(1/8)*cos(alpha*s)*(BesselY(0, beta*s)*Pi+2*BesselK(0, beta*s))/(beta^2*Pi)-((1/8)*I)*cos(alpha*s)*BesselJ(0, beta*s)/beta^2

int(another, s=0..infinity): simplify(%) assuming conds; # Bah
evalf(eval(%, [alpha=1,beta=3/2]));

(1/8)/(beta^2*(alpha^2+beta^2)^(1/2))

0.3081667757e-1

int(another, s=0..infinity) assuming conds: simplify(%) assuming conds;
evalf(eval(%, [alpha=1,beta=3/2]));

-((1/8)*I)*Heaviside(beta-alpha)/((-alpha^2+beta^2)^(1/2)*beta^2)-(1/8)/(beta^2*(alpha^2-beta^2)^(1/2))+(1/8)*Heaviside(beta-alpha)/(beta^2*(alpha^2-beta^2)^(1/2))+(1/8)/(beta^2*(alpha^2+beta^2)^(1/2))

0.3081667757e-1-0.4969039948e-1*I

int(evalc(Re(newig)+Im(newig)*I), s=0..infinity) assuming conds;
simplify(%) assuming conds;
evalf(eval(%, [alpha=1,beta=3/2]));

(1/2)*2^(1/2)*Pi^(1/2)*(-((1/8)*I)*2^(1/2)*Heaviside(beta-alpha)/(Pi^(1/2)*(-alpha^2+beta^2)^(1/2)*beta^2)-(1/8)*2^(1/2)*Heaviside(-beta+alpha)/(Pi^(1/2)*(alpha^2-beta^2)^(1/2)*beta^2)+(1/8)*2^(1/2)/(Pi^(1/2)*(alpha^2+beta^2)^(1/2)*beta^2))

-((1/8)*I)*Heaviside(beta-alpha)/((-alpha^2+beta^2)^(1/2)*beta^2)-(1/8)/(beta^2*(alpha^2-beta^2)^(1/2))+(1/8)*Heaviside(beta-alpha)/(beta^2*(alpha^2-beta^2)^(1/2))+(1/8)/(beta^2*(alpha^2+beta^2)^(1/2))

0.3081667757e-1-0.4969039948e-1*I

 


Download IntcosBesselJ.mw

[edited] Somehow I missed the following simpler variant, in which after converting to the integrand `Bessel` the extra assumptions on the Bessel calls are not needed. (I wonder what I was doing that made me think it was needed above... likely I just got confused.)

restart;

kernelopts(version);

`Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877`

integrand:=cos(alpha*s)*(1/8*I)*(-HankelH1(0, beta*s)-(2*I)*BesselK(0, beta*s)/Pi)/beta^2;

((1/8)*I)*cos(alpha*s)*(-HankelH1(0, beta*s)-(2*I)*BesselK(0, beta*s)/Pi)/beta^2

ans1:=int(convert(integrand,Bessel), s=0..infinity) assuming alpha>0, beta>0;

(1/2)*2^(1/2)*Pi^(1/2)*(-((1/8)*I)*2^(1/2)*Heaviside(beta-alpha)/(Pi^(1/2)*(-alpha^2+beta^2)^(1/2)*beta^2)-(1/8)*2^(1/2)*Heaviside(-beta+alpha)/(Pi^(1/2)*(alpha^2-beta^2)^(1/2)*beta^2)+(1/8)*2^(1/2)/(Pi^(1/2)*(alpha^2+beta^2)^(1/2)*beta^2))

ans2:=simplify(convert(ans1,piecewise,alpha)) assuming alpha>0, beta>0;;

ans2 := piecewise(alpha < beta, -(I*sqrt(alpha^2+beta^2)-sqrt(-alpha^2+beta^2))/(8*sqrt(alpha^2+beta^2)*beta^2*sqrt(-alpha^2+beta^2)), alpha = beta, ((undefined*sqrt(alpha^2+beta^2)*beta^2+sqrt(alpha^2-beta^2))*sqrt(-alpha^2+beta^2)+(undefined*I)*sqrt(alpha^2-beta^2)*sqrt(alpha^2+beta^2)*beta^2)/(8*sqrt(alpha^2-beta^2)*sqrt(-alpha^2+beta^2)*sqrt(alpha^2+beta^2)*beta^2), beta < alpha, (sqrt(alpha^2-beta^2)-sqrt(alpha^2+beta^2))/(8*sqrt(alpha^2+beta^2)*beta^2*sqrt(alpha^2-beta^2)))

evalf(eval([ans1,ans2,Int(integrand,s=0..infinity)], [alpha=1,beta=3/2]));

[0.3081667754e-1-0.4969039945e-1*I, 0.3081667754e-1-0.4969039949e-1*I, 0.3081667757e-1-0.4969039950e-1*I]

evalf(eval([ans1,ans2,Int(integrand,s=0..infinity)], [alpha=2,beta=3/2]));

[-0.1977383032e-1, -0.1977383033e-1, -0.1977383033e-1+0.6e-13*I]

plots:-display(
    plot3d([Re,Im](ans1),alpha=0..beta,beta=0..2, view=-1..1, color=[red,blue], grid=[600,50], style=surface),
    plot3d([Re,Im](ans1),alpha=beta..2,beta=0..2, view=-1..1, color=[red,blue], grid=[600,50], style=surface)
);

 


Download IntcosBesselJ_2.mw

The name Psi is the name of an assigned special function in Maple. Use another name. Eg,

restart;
with(PDEtools):

U := diff_table(PSI(`&psi;_2`, `&psi;_1`)):

pde := `&psi;_2`*(diff(PSI(`&psi;_2`,`&psi;_1`),`&psi;_1`))+`&psi;_1`*U[`&psi;_1`]+2*U[] = 0:

pdsolve(pde);

                                   _F1(&psi;_2)
          PSI(&psi;_2, &psi;_1) = --------------------
                                                    2
                                 (&psi;_1 + &psi;_2)

The most important thing that I suspect you might not have realized is that there is a huge difference between the typeset 2D Math ft as a unit (which gets pretty-printed in upright roman font) versus ft as a name (which gets pretty-printed in italics).

Before Maple 2017 units were typeset within double-brace fencing. In Maple 2017 the braces have gone, which is nice for some people but confusing for others.

There are three common ways to enter an actual unit:
1) Using the Units palette (in the left panel of the GUI). This always typesets it in upright roman, even for input.
2) Typing the keystrokes Unit, and then either typing in round-brackets to make that a function call, or using command-completion (Esc key, say) to turn such 2D Input into the brace-less upright roman font form.
3) Typing keyboard accelerations like Alt-shift-u (for Linux, but varies with platforms) to get into unit entry mode.

Attached below are a Worksheet with 1D Maple Notation and a Document with 2D Input (I used command-completion to enter all the units for the Document).

I've utilized the Units:-Simple package so that arithmetic operations done at the top-level combine units.

I've shown the combine(...,units) command which is the best way to combine units into the "base unit" for the final dimensions of a result.

I've used the Units:-UseUnit command to force the "base unit" for several different combinations of dimension (you may wish to augment this). I find this much superior to the right-click Units Formatting since the latter has to be done every time one wants a result in a preferred unit rather than the default unit for a given dimension.

units1.mw

units2.mw

I'll also mention that if you loaded the Units:-Natural package (instead of Units:-Standard or Units:-Simple) then you would be able to type in names and symbols of units without any extra work (palettes, Unit() command, keyboard acceleration, etc). That's how many Mathcad users are used to doing things. The problem with that scheme in Maple is that things get just too awkward with such a huge number of single-letter names being effectively removed from one's global namespace. Almost nobody uses Units:-Natural . (I consider it unworkable, and wish it would go away...) If you do  not load this subpackage then you cannot simply type a name like `feet` and have Maple interpret it as a unit, but instead you need to use 1), 2), or 3) above (or cut & paste from some actual unit).

Once again, it appears that you are looking for pretty-printed output, since for 2D Input there's little difficulty.

I'll leave aside the approach of building it with the mouse using palettes (or command completion for the Greek), and then conversion to Atomic Identifier via the right-click menu. You've been shown that in another recent thread.

We can construct TypeMK (the stuff that atomic identifiers are made of) for this.

 

Using TypeMK.

 

A + `#mrow(msub(mn("&lambda;"),mn("1")),mi("I"));` = <1,2; 3,4>;

"A+lambda[1]I=[[[1,2],[3,4]]]"

 

And now with upright roman A and I.

 

`#mn("A")` + `#mrow(msub(mn("&lambda;"),mn("1")),mn("I"));` = <1,2; 3,4>;

"A+lambda[1]I=[[[1,2],[3,4]]]"

 

And now with upright roman A and I, in bold.

 

`#mn("A",fontweight = "bold")`
+ `#mrow(msub(mn("&lambda;"),mn("1")),mn("I",fontweight = "bold"));` = <1,2; 3,4>;

"A+lambda[1]I=[[[1,2],[3,4]]]"

NULL


Download typemk.mw

Presumably your question is about the pretty-printing of 2D Math output.

This was done in Maple 16.02, but may work in your Maple 13.
 

restart

M := Matrix([[1, 2], [3, 4]])

Matrix(%id = 18446884297779762110)

 

For these next two examples I used the right-click context menu to turn the LHS into atomic identifiers.

NB. This second example still has the usual Matrix brackets (round when typesetting level is standard, and square when extended) inside the vertical bar fencing, however. And that's not what was requested.

 

`#mrow(mo("&verbar;"),mi("M"),mo("&verbar;"))` = LinearAlgebra:-Determinant(M)

`#mrow(mo("&verbar;"),mi("M"),mo("&verbar;"))` = -2

`#mrow(mo("&verbar;"),mfenced(mtable(mtr(mtd(mn("7")),mtd(mn("2"))),mtr(mtd(mn("3")),mtd(mn("3")))),open = "&lsqb;",close = "&rsqb;"),mo("&verbar;"))` = LinearAlgebra[Determinant](Matrix(2, 2, {(1, 1) = 7, (1, 2) = 2, (2, 1) = 3, (2, 2) = 3}))

`#mrow(mo("&verbar;"),mfenced(mtable(mtr(mtd(mn("7")),mtd(mn("2"))),mtr(mtd(mn("3")),mtd(mn("3")))),open = "&lsqb;",close = "&rsqb;"),mo("&verbar;"))` = 15

 

The last two examples are done without using atomic identifiers.

 

They simply wrap the LHS with uneval quotes (single right quotes), and then rely on the following custom printing function.

 

This custom printing procedure could be put in the Startup Code Region of the Document/Worksheet, or put in one's Maple initialization file.

 

`print/Determinant`:=proc(A)
  uses Typesetting;
  if not type(eval(A),Matrix) then error "expecting a Matrix"; end if;
  mrow(mo("&verbar;"),eval(Typeset(EV(A)),mfenced=(x->x)),mo("&verbar;"));
end proc:

'abs(M)' = abs(M)

LinearAlgebra:-Determinant(M) = -2

'LinearAlgebra:-Determinant(M)' = LinearAlgebra:-Determinant(M)

LinearAlgebra:-Determinant(M) = -2

 


Download verbar.mw

@mapleatha 

In 2D Input mode you can enter A=B=C , or A+lamda I = A+ 4I = B , say. Then right-click on it and choose the context-menu action 2-D Math -> Convert To -> Atomic Variable in the menus that pop up. That turns it into a name which pretty-prints as output like the original input. In Maple 13 it is called an Atomic Identifier, I believe.

You can also create 2D Math expressions which do not execute, and you can also intersperse those within paragraphs of text, say. That is possible in Maple 13 too, I believe.

In a Document in Maple 2017 you could also enter such a thing in 2D Input, and then hover the mouse cursor near its end to reveal a round toggle button that can be used to disable execution of the line.

In this was you can create quite a variety of expository mathematical formulas which don't necessarily have to parse and evaluate to valid Maple language constructs.

In the example Document below I used the right-click conversion to the inputs assigned to foo and bar, and toggled the Q+R+S to non-executable. This was in Maple 2017.3.

restart

foo := `#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

`#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

foo

`#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

bar := `#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&InvisibleTimes;"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

`#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&InvisibleTimes;"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

bar

`#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&InvisibleTimes;"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

Q+R+S

5

5

``

 

Download 2datomic.mw

Here are some examples executed in Maple 13 (including convert-to-atomic-identifier on the rhs of the assignments to foo and bar).

The left-alignment below is an artefact of inlining into Mapleprimes; the items were centered in Maple 13's GUI.

restart

x := 7;

7

(1)

foo := `#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

`#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

(2)

foo;

`#mrow(mi("A"),mo("&equals;"),mi("B"),mo("&equals;"),mi("C"))`

(3)

bar := `#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

`#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

(4)

bar

`#mrow(mi("A"),mo("&plus;"),mi("&lambda;",fontstyle = "normal"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("A"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mi("I"),mo("&equals;"),mi("B"))`

(5)

This is some text and some math such as sqrt(sin(Pi/x))or x = foo and foo = baror A=B=C is inlined. I use Ctl-r to switch to 2D Math entry mode and Ctl-t to switch to text mode.

 

5

5

(6)

`#mrow(mfenced(mtable(mtr(mtd(mn("1")),mtd(mn("3"))),mtr(mtd(mn("7")),mtd(mn("9")))),open = "&lsqb;",close = "&rsqb;"),mo("&plus;"),mfenced(mtable(mtr(mtd(mi("a")),mtd(mi("b"))),mtr(mtd(mi("c")),mtd(mi("d")))),open = "&lsqb;",close = "&rsqb;"),mo("&equals;"),mfenced(mtable(mtr(mtd(mn("1")),mtd(mn("3"))),mtr(mtd(mn("7")),mtd(mn("9")))),open = "&lsqb;",close = "&rsqb;"),mo("&plus;"),mn("4"),mo("&InvisibleTimes;"),mfenced(mtable(mtr(mtd(mn("1")),mtd(mn("0"))),mtr(mtd(mn("0")),mtd(mn("1")))),open = "&lsqb;",close = "&rsqb;"),mo("&equals;"),mfenced(mtable(mtr(mtd(mn("5")),mtd(mn("3"))),mtr(mtd(mn("7")),mtd(mn("13")))),open = "&lsqb;",close = "&rsqb;"))`

(Matrix(2, 2, {(1, 1) = 1, (1, 2) = 3, (2, 1) = 7, (2, 2) = 9}))+(Matrix(2, 2, {(1, 1) = a, (1, 2) = b, (2, 1) = c, (2, 2) = d})) = (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 3, (2, 1) = 7, (2, 2) = 9}))+4*(Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 1) = 0, (2, 2) = 1})) and (Matrix(2, 2, {(1, 1) = 1, (1, 2) = 3, (2, 1) = 7, (2, 2) = 9}))+4*(Matrix(2, 2, {(1, 1) = 1, (1, 2) = 0, (2, 1) = 0, (2, 2) = 1})) = (Matrix(2, 2, {(1, 1) = 5, (1, 2) = 3, (2, 1) = 7, (2, 2) = 13}))

(7)

``

NULL


Download 2dm13.mw

Using Maple 2017.2,

restart;

assume(nu > 2, beta > 0, lambda > 0, delta > 0, y >= 0):

S:=dsolve(beta+y+(D(h))(y) = nu*((lambda+beta+y)^2-delta*h(y))^(1/2)):

subsindets(simplify(S),RootOf,u->map(simplify,u));

[edited: I see that the OP has since indicated he is using 2016.2]

For Maple 2016.2 you could try instead,

subsindets(simplify(simplify(S),size), RootOf,
           u->map(uu->simplify(simplify(uu),size),u));
In Maple 2017 the `simplify` command (without extra argument) does the additional actions of `simplify(...,size)` even when not executed at the top-level.

The syntax to load the package is,

   with(simplex)

and not,

   with simplex

as your Comment indicates.

Note the there should be no space between the "h" of "with" and the opening round bracket.

The round brackets are required, since here they denote a function call to the `with` command, and they are not merely separators.

Since the problem appears to be with just the pretty-printing of those names then you should be able to get by, say by avoiding that. (You don't need them beautiful for some purpose, do you?)

If you don't want to have to temporarily switch typesetting level then you could lprint or sprintf or print (or suppress output).

This has been reported as a bug on this site before, btw.

Consider your first example. It is not working for the reason you think, I suspect. What seems more likely is that plot3d is receiving as its first argument the list of three scalar expressions in x and y that is returned by the evaluation of se(x,y) where x and y have no assigned values. In this way that call plot3d(se(x,y),x=0..2,y=-2..3) matches a valid and documented calling sequence of the plot3d command.

For your second example plot3d(td(x,t),x=0..2,t=0..3) your should first execute the call td(x,t) and see what it returns. That is what you are passing to the plot3d command here.

The plot3d command, like most Maple commands, follow the so-calling standard evaluation rules of evaluating arguments before they are passed to the procedure.

A procedure (of say two arguments) which returns a list of three elements is not one of the valid calling sequences of the plot3d command. An unevaluated function call, like say the single right-quoted call 'td(x,t)' , which might evaluate to a 3 element list when x and t take on values, is also not a valid calling sequence of the plot3d command.

For Question 1:

Depending on your specific architecture hyperthreading may or may not interfere with  the efficiency of Grid computations.

You could see what happens if you disable hyperthreading in your machine's BIOS.

One scenario in which the derivatives appearing in the prettyprinting of a "Vector" do not get formatted in dot-notation is when it is handling a VectorCalculus:-Vector. I don't see mention of that package in your Question.

If you are using the global constructor :-Vector when you use the shortcut <...> (by virtue of not having loaded VectorCalculus, say) then it seems to work OK in Maple 2016.2. See attachment.

If you do indeed want VectorCalculus loaded and/or want its results to be prettyprinted with dot-notation, then you could get dot-notation for its "Vector" results by wrapping them in the command :-Vector(...) . That would give you the BasisFormat(false) appearance. I don't see any easy way to get the dot-notation displayed in the BasisFormat(true) style in Maple 2016.2.

usedot20162.mw

 

Your posted example suffers from computational issues (e.g roundoff error), rather than a display-driver problem.

Short workaround:

restart;
CodeTools:-Usage( plot(x->eval(evalf[20]((1-x)^(10^9))), 0..10^(-15)) ):
memory used=6.48MiB, alloc change=33.00MiB, cpu time=36.00ms, real time=39.00ms, gc time=0ns

Usually a more natural way to deal with such an issue is simply to raise Digits at the level at which you are calling plot. But, as seen at the end of the following code, there are some unexpected issues with that approach for your example as given.

(Link to the attached worksheet is at the end.)

restart;

# This is the simplest workaround I know to the computational
# difficulties and bugs under the `plot` code here.
#
# You can read all the material later on, for details. The
# essence is that we seem currently stuck between these choices:
#
# A) Allow `evalhf` mode.
# B) Disable `evalhf` mode but then get stuck within `plot/adaptive/drive`.
#
# Since B) goes away for a very long time, we'll have to use A).
# Since `evalhf` now allows one to raise `Digits` within a procedure (but then
# ignores it!) we'll have to use `eval` to escape the procedure and make its
# own forcing call to `evalf[25]` with higher working precision.

plot( proc(x)
        eval(evalf[25]( (1-x)^(10^9) ));
      end proc,
      0..10^(-15) );
            

restart;

interface(rtablesize=20):
N:=19;

19

# Let's attempt to force higher working precision by:
#
# 1: Using so-called operator/procedure form for the thing to plot.
# 2: Setting `UseHardwareFloats` to `false`.
# 3: Raising Digits within the procedure to be plotted.
#

G:=proc(x) Digits:=25; (1-x)^(10^9); end proc:

G(1e-11);

# Note that the following does not produce an error from `evakhf`,
# even though G contains a line which assigns to Digits.
# That became possible some major releases ago.

evalhf( G(1e-11) );

.9900498337491185510822182

.990049832929947637

# Something to investigate late on is whether the following computes
# the plot data under `evalhf` or not!

Digits:=15:
UseHardwareFloats:=false:

P:=plot(G, 0..10^(-15), adaptive=false, numpoints=N):
P;

W:=op([1,1],P);

_rtable[18446883879575052646]

#Let's create the Vector of independent data ourselves;
#
# This is perhaps the simplest workaround to the problem under discussion.

V:=Vector(N,(i)->evalhf(0+(1e-15-0)*(i-1)/(N-1)),datatype=float[8]):
Y:=Vector(map( proc(x) Digits:=25; (1-x)^(10^9); end proc, V), datatype=float[8]):
<V|Y>;

plot(<V|Y>);

_rtable[18446883879575060838]

# So it's a little weird that the independent data is not evenly spaced,
# while we forced `adaptive`=false and `numpoints`.
#
# But that doesn't seem to be the problem. The problem is that the
# dependent data in the bad PLOT doesn't seem to match what we get when
# we apply the very same procedure to its independent data.
#

# Let's take the independent data (first column) in the bad PLOT
# structure and compute the dependent data from it (at higher precision).
#
# The compare this with the original bad plot.

U:=Vector(map( proc(x) Digits:=25; (1-x)^(10^9); end proc, W[..,1]), datatype=float[8]):
W[..,2], U;

plots:-display(plot(<W[..,1]|U>,color=green), plot(<W[..,1]|W[..,2]>,color=red) );

Vector(19, {(1) = 1., (2) = .99999988897770375, (3) = .99999988897770375, (4) = .99999988897770375, (5) = .99999977795541972, (6) = .99999966693314812, (7) = .99999966693314812, (8) = .99999966693314812, (9) = .99999955591088874, (10) = .99999944488864179, (11) = .99999944488864179, (12) = .99999944488864179, (13) = .99999933386640705, (14) = .99999922284418474, (15) = .99999922284418474, (16) = .99999922284418474, (17) = .99999911182197476, (18) = .99999911182197476, (19) = .99999900079977699}), Vector(19, {(1) = 1., (2) = .99999994187425734, (3) = .99999989129936195, (4) = .99999983442260587, (5) = .99999977716883703, (6) = .99999972018718852, (7) = .99999966735790924, (8) = .99999961265625337, (9) = .99999955608372570, (10) = .99999949969263013, (11) = .99999944168746024, (12) = .99999939059647791, (13) = .99999933308013567, (14) = .99999927532762922, (15) = .99999921967239114, (16) = .99999916913210574, (17) = .99999910903482137, (18) = .99999905812454137, (19) = .99999900000050002})

# This "runs away" inside `plot/adaptive/driver`.
# But surely it should even get there, because we supply `adaptive`=false and `numpoints`.
#
# I suspect that the control code is mistakenly dispatching to `plot/adaptive/driver`
# when it encounters the following error while trying `evalhf` mode.
#
# nb. The lists creation in this procedure is there to make `evalhf` emit an error.
#
# I'll submit a bug that it's going in to `plot/adaptive/driver` at all.

F := proc(x) Digits:=25; []; (1-x)^(10^9); end proc:
F(1e-10);

evalhf(F(1e-10));

.9048374180314353860737790

Error, unable to evaluate expression to hardware floats: []

# This now runs amok and requires computation to be interrupted.

plot(F, 0..10^(-15), adaptive=false, numpoints=N):

Warning,  computation interrupted

restart;

# Similarly, it also runs amok (again, within `plot/adaptive/driver` even
# though we supply `adaptive`=false and `numpoints`) with the following.
#
# This too requires computation to be interrupted.
#
# I'll submit a bug that it's going in to `plot/adaptive/driver` at all.

Digits:=25:

plot( x->(1-x)^(10^9), 0..10^(-15), adaptive=false, numpoints=19):

Warning,  computation interrupted

 

 

plotprob.mw

First 190 191 192 193 194 195 196 Last Page 192 of 336