C_R

2340 Reputation

19 Badges

4 years, 302 days

MaplePrimes Activity


These are replies submitted by C_R

Solving by hand an explicit solution can be derived

sol:=dsolve(ode);
subs(x=a,y(a)=b,%):
map(tan,%);
solve(%,{c__1});
simplify(subs(%[1],sol));

This solution is too complex for odetest. However, when arctan(y,x) is converted to arctan the IC is correctly reproduced.
 

@acer 

The example is probably too simplistic in the sense that a user would not use has on such a simple expression. It’s obvious from the screen. In the original expression the search pattern was larger and very similar expressions were presented on a screen filling output. The user could not substitute expressions he saw on screen. To understand the problem, has was used, which surprisingly did not work as expected.

New users to Maple learn denom before they discover (if ever) that Maple does not use quotients internally. This can lead to the contradicting situation where a product has a denominator

I/sqrt(a):
whattype(%);
denom(%%)
                               I   
                             ------
                              (1/2)
                             a     

                               *

                              (1/2)
                             a     

Kitonum explains in more detail why Maples output “false” is technically correct – a view on has from Maples internal representation. nm’s answer focusses on the pretty printed output and provides the expected answer “true” – a has varaint for GUI /pretty print.

Your reply adds the aspect of collecting/factoring an expression (that is not a subexpression) in an expression. This is beyond pattern matching of subexpressions and common-sense interpretation of has (which could lead as we discuss here to incomprehension when the internal functioning of Maple is not known).  

Your answer has(%,{a^(1/2),a^(-1/2)}) tells me that there is no “GUI has”.  I think it’s a good example to raise awareness that has does not always produce the expected answer when used in for GUI output. Since decomposing of a complex expression with op  is not straight forward (to understand the structure of an expression), I wonder whether indets would have given a better indication that I/sqrt(a) does not contain sqrt(a). If so a link on the help page of has could be beneficial in addition to a note and/or example that has is designed for the internal representation of an expression. This could help making an important learning step in case has is used.

@Ronan 

Looks like that \n does not work inside Typeset and that there is no new line MathML tag that can be used instead with Typeset.

By the way, typeset or Typeset in my former examples with mover is not needed when Typesetting is loaded

display(point(Pgamma2, symbol = solidcircle, symbolsize = 14), textplot([Pgamma2[], mover(mo("⁢"), mo("γ2")), align = {above}]))

For me the lower case typeset is an unlucky choice. Too close to Typeset but not the same. 

@acer 

Somehow \n is not working. What is wrong with my trials?

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],Typeset((`gamma2`,"\n" )),align={above}])); # this is what I tried before mover
display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],typeset(Typeset((`gamma2`,"\n" ))),align={above}]))

@dharr 
I would have expected the floats to trigger this in the same way the limits do. In both cases the solution is not exact.
The error must be somewhere else because int integrates numerically.

infolevel[int]:=5

Update:

 

The inner and integral yields a piecewise expression with conditions on y with is 3 times Float(undefined) and a big expression otherwise. This big expression does not evaluate to 0.2080471649. There is clearly something not working as it should.

@Ronan 

It's not really documented. Apart from 

Most other Typesetting exports correspond to either internal-use routines or typesetting tags, which roughly correspond to MathML tags. (from the Typesetting helppage)

I got most help from Acer and Carl Love. And, since I am not typesetting on a regular base my frist command was unnecessary long. Here is a shorter version

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],Typeset(mover(mo("⁢"),mo("γ2"))),align={above}]))

that skips the longform (no mention of the typeset package). Took me a while to figure out that when calling plot (Edit: sometimes but not allways) typeset perfroms the same as Typesetting:-Typeset.
 

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],typeset(mover(mo("⁢"),mo("γ2"))),align={above}]))

An important other tag is mi for italic.

If 2D-Math is accepable there is a much easier way using the palettes which you can also use to learn type setting in 1D.
 

with(plots):with(plottools):

with(Typesetting):

From the Layout palette take `#mover(mi("A",mathcolor = "#00a050"),mi("b",mathcolor = "#c800c8"))`and make it an atomic variable

`#mrow(mo("⁢"),mover(mi("A",mathcolor = "white"),mi("γ2")))`

`#mrow(mo("⁢"),mover(mi("A",mathcolor = "white"),mi("γ2")))`

(1)

Pgamma2 := [3/2, 5/2]

[3/2, 5/2]

(2)

Copy paste the atomic variable in 2d-Math

display(point(Pgamma2, symbol = solidcircle, symbolsize = 14), textplot([Pgamma2[], Typeset(`#mrow(mo("⁢"),mover(mi("A",mathcolor = "white"),mi("γ2")))`), align = {above}]))

 

Copy past the the 2D-Math an convert it to 1D

display(point(Pgamma2, symbol = solidcircle, symbolsize = 14), textplot([Pgamma2[], Typeset(`#mrow(mo("⁢"),mover(mi("A",mathcolor = "white"),mi("γ2")))`), align = {above}]))

NULL


 

Download MathML.mw

should this be Pgamma2

@nm 

There can be many reasons why a graphic card is part of an issue. For example, the system is configured not to use the graphic card and used the internal graphic adpter.

You can check this in the task manager under GPU. With the NVDIA control center you can force which adapter is used by javaw.exe.

A driver update could make sense.

I am on Windows 10.

@nm 

no hang when printing but when expanding. The thread 0x000000000000, to what I have observed so far, signals a dead end. 

And no black window. You should have an NVIDIA control pannel. You could check under 3d settings which graphic processor is used. My system is set to automatic.

Allocated memeory was also moderate.

Strange.

That was with

The superposition of two linear polarized orthogonal waves can create circular polarization provided that there is an appropriate phase shift beween the waves.
The compound field vector is often animated as a rotating vector where the tip is describing a helical path.

What I like about your way of generating the helix is the use of sectioning of two surfaces. It's the first time I see it this way. The compact and clean coding is nice as well.

@nm 

Could you provide a test file? What I see in your video is extreme. I only have these black or clipped windows when I have a Maple session running for a long time with many worksheets open. The clipping is also visible in other applications running in parallel which is an indication that the memory for the graphics adapter (virtual or phsyical?) is running out.

After a logout from Windows everything is back to normal.

Anything special about your graphic adapters?

 

Yes, I had this before. It happens from time to time and I assume it is related to Java and Windows.

If Crtl,Shift,Enter still executes the worksheet then something hinders the GUI to enable the !!! button.

You could also try to change worksheet tabs to see if that enables the button. This "method" enabled in some instances the interupt button.

@ecterrab 

I have done a punctual check of the new solutions provided by dAlembert. Looks good, but provides less solutions in the real domain.
For me it is not a first choice to solve this initial value problem. odeadvisor still does not list this type. Is it for the reason that other methods are considered superior? Anyway, IVPs leads me to a subtely that I overlooked when speculating about odeadvisor.

odeadvisor advises on ordinary differential equations and not on initial value problems. In this sense, no suggestions on methods are made to solve an IVP. 👍

@dharr 

 

I have tried on the solution obtained with the dsolve method dAlembert

subs(x=-4,sol);
allvalues(%,implicit = true);

Only one root is obtained for negative x whereas 3 roots are obtained for x beeing positive. To make sure I also set one of the roots not obtained with dAlembert as root selector

RootOf(op(rhs(sol)),-4.725448724):
allvalues(subs(x=-4,%));
evalf(%);


-> -4.721 is not a root.

Looks to me that the RootOf expression obtained with dAlembert is not pointwise equivalent to your implicit solution. It provides less solutions to the ode. All that assuming that RootOf performs as described on the allvalue helppage  (i.e. it provides all roots).

Again 👍👍

@dharr 

Its apparent from your solution that allvalues did not provide all solutions when working symbolically and did also not warn about missing solutions when working numerically. Why allvalues decided to solve numerically in one case is still unclear.

Implicitly your answer sheds light on questions about the results of dsolve depending on solution methods. That is very revealing.

Thanks allot!

1 2 3 4 5 6 7 Last Page 1 of 44