acer

32348 Reputation

29 Badges

19 years, 329 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@Carl Love He has inf=1 in the upper BCs (which happens to exceed the plotting range), but it's not clear yet whether he'll eventually want a greater value and run into convergence issues.

@panke Why don't you upload and attach your worksheet?

(Btw, why not utilize print around display?) [edit] Why ignore my earlier advice?

 

@pik1432 If you had asked that question about structure and representation on its own then I might just point you to the Help pages on:
  dismantle
  ToInert
and the Programming Guide sections:
  Internal Representation
  Types and Operands

But given your original Question in this thread, I'll explain some of the steps, from an "operand" point of view.

restart;

subexp := M__a*sin(omega*t + alpha)*I__a*sin(omega*t + phi);

M__a*sin(omega*t+alpha)*I__a*sin(omega*t+phi)

# As mentioned before, this factors out the 2, and
# it seems you don't want that. So an alternate approach
# involves splitting the product into the multiplicands
# which are trig calls from those which are not.
#
combine(subexp);

(1/2)*M__a*I__a*(cos(alpha-phi)-cos(2*omega*t+alpha+phi))

op(0, subexp);  # It is a product

`*`

op(subexp);     # A sequence of the operands

M__a, sin(omega*t+alpha), I__a, sin(omega*t+phi)

nops(subexp);   # The number of operands

 

4

for i from 1 to nops(subexp) do
  print(op(i,subexp));
end do;

M__a

sin(omega*t+alpha)

I__a

sin(omega*t+phi)

# Select only those operands of a certain type.
# Note the the result has the same 0-th (zeroth)
# operand, it result is also of type `*`.
#
select(type, subexp, trig);

sin(omega*t+alpha)*sin(omega*t+phi)

# Remove only those operands of a certain type.
#
remove(type, subexp, trig);

M__a*I__a

# Split only the operands according to a certain type.
# Note: this returns a pair of `*` expressions -- one from
# the `select` and one from the `remove`.
#
selectremove(type, subexp, trig);

sin(omega*t+alpha)*sin(omega*t+phi), M__a*I__a

# Perform an operation on the two separate pieces.
# (I could has assigned them to temp names and acted
# differently on each. But the `combine` happens to not
# do anything to the other, here.
#
map(combine, [selectremove(type, subexp, trig)]);

[(1/2)*cos(alpha-phi)-(1/2)*cos(2*omega*t+alpha+phi), M__a*I__a]

# Multiply those two results.
#
`*`( op(map(combine, [selectremove(type, subexp, trig)])) );

M__a*I__a*((1/2)*cos(alpha-phi)-(1/2)*cos(2*omega*t+alpha+phi))

 

# And now, just in case you find it interesting...
dismantle(subexp);


PROD(9)
   NAME(4): M__a
   INTPOS(2): 1
   FUNCTION(3)
      NAME(4): sin #[protected, _syslib]
      EXPSEQ(2)
         POLY(6)
            EXPSEQ(4)
               NAME(4): alpha
               NAME(4): omega
               NAME(4): t
            DEGREES(HW): ^2 ^0 ^1 ^1
            INTPOS(2): 1
            DEGREES(HW): ^1 ^1 ^0 ^0
            INTPOS(2): 1
   INTPOS(2): 1
   NAME(4): I__a
   INTPOS(2): 1
   FUNCTION(3)
      NAME(4): sin #[protected, _syslib]
      EXPSEQ(2)
         POLY(6)
            EXPSEQ(4)
               NAME(4): omega
               NAME(4): phi
               NAME(4): t
            DEGREES(HW): ^2 ^1 ^0 ^1
            INTPOS(2): 1
            DEGREES(HW): ^1 ^0 ^1 ^0
            INTPOS(2): 1
   INTPOS(2): 1
 

ToInert(subexp);

_Inert_PROD(_Inert_NAME("M__a"), _Inert_FUNCTION(_Inert_ASSIGNEDNAME("sin", "PROC", _Inert_ATTRIBUTE(_Inert_EXPSEQ(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))), _Inert_NAME("_syslib")))), _Inert_EXPSEQ(_Inert_SUM(_Inert_PROD(_Inert_NAME("omega"), _Inert_NAME("t")), _Inert_NAME("alpha")))), _Inert_NAME("I__a"), _Inert_FUNCTION(_Inert_ASSIGNEDNAME("sin", "PROC", _Inert_ATTRIBUTE(_Inert_EXPSEQ(_Inert_NAME("protected", _Inert_ATTRIBUTE(_Inert_NAME("protected"))), _Inert_NAME("_syslib")))), _Inert_EXPSEQ(_Inert_SUM(_Inert_PROD(_Inert_NAME("omega"), _Inert_NAME("t")), _Inert_NAME("phi")))))

 

Download op_example.mw

@Katatonia I suggest that you upload and attach your complete code and worksheet to a Reply.

(The failure of the numeric integration involving Y5 may be just a matter of working precision and tolerance, but why guess?)

@pik1432 One of my points is that it's easy to simply type this in:

M__a*I__a*combine(sin(omega*t+alpha)*sin(omega*t+phi));

       M__a I__a (1/2 cos(alpha - phi) - 1/2 cos(2 omega t + alpha + phi))

But doing so (and the same for similar approaches where you have to manually separate or introduce the M__a*I__a factor) is rather ad hoc.

I'd like an ARM port of the kernel and command-line interface.

Here is the original text of the Post (since removed by the OP):

"I need to use the U.I. because I'm doing graphing. I need to use CAS, because I'm doing symbolic calculations. Between Maple and Mathematica, I have zero options whose user-interfaces don't infuriate me to the point, where I spend substantially less time doing math, and substantially more time feeling angry. Interacting with the user-interfaces, is akin to a physical fight, and it puts me in a fighting mood. You can find me stomping around outside smoking cigarettes after my attempts to use Maple. I have no other option if I want to get these plots done. The issue isn't me; I don't have this issue with math outside of professional CAS's, and I don't have this issue with software in general, which I've been using and programming since 1980. There've been better user-interfaces since 1985. As a programmer, I've been editing structured documents for decades.

I was excited to get out of bed in the morning during the Python / Numpy / Matplotlib phase of this project. Now that I'm in the Maple phase, I'm dreading work and hating life until I get these plots done.

It's ridiculously difficult to select text without the user-interface selecting the wrong amount of text because it thinks it knows better. I spend over half my time in this program battling the user-interface, not doing math.

Many times a day, an attempted edit goes so wrong, and ctrl-z doesn't fix things, that I have to close my document without saving and re-load the document. Compare that to other software.

CAS could be such good software, if it learned from other software. Instead, professional CAS devevelopers make mistakes other software companies have fixed for decades. Both CAS companies. Every part of this project I can do in Jupyter / Python / Numpy / Matplotlib, I use those instead of Maple. I use Maple only where absolutely necessary. It's a necessary evil in my work-flow. There's no good reason for CAS to be that.

Cursor flickering maniacally when I try to select text in a document. Who really wants that?

Many bugs compared with other professional user-interfaces."

@DJJerome1976 In the attachment in my Reply I showed both.

@DJJerome1976 I'm not sure whether you meant the intersection of the complement of A along with B, or the intersection of the complement of both.

You can use Not along with And and Or.

(Mapleprimes doesn't want to inline this sheet right now, sorry.)
Download solve_RR_2.mw

 

@DanFromDK 

restart

kernelopts(version)

`Maple 2020.1, X86 64 LINUX, Jun 8 2020, Build ID 1474533`

with(Units:-Simple); Units:-UseUnit(J/(kg*K))
 

m := .25*Unit('kg'); Q := 22.5*Unit('kJ'); `ΔT` := 100*Unit('K')

100*Units:-Unit(K)

combine(isolate(Q = m*c*`ΔT`, c), units)

c = 900.0000000*Units:-Unit(J/(kg*K))

NULL

Download Unit_problem_version_1_ac.mw

note: I only used simplify in an example in my Answer because you had it in your Question. I prefer to use combine(.., units) to get the base units in the current system, combined.

@rlopez Thank you, Robert. thats a good point. Perhaps the OP wants something like this:

restart;

with(VectorCalculus):

 

F := exp(x*y^3*z^2):

 

# returns a vector field
VFG := Gradient(F,[x,y,z]);

Vector(3, {(1) = y^3*z^2*exp(x*y^3*z^2), (2) = 3*x*y^2*z^2*exp(x*y^3*z^2), (3) = 2*x*y^3*z*exp(x*y^3*z^2)})

 

# returns a rooted vector
evalVF(VFG, <[1,-1,2]>);

Vector(3, {(1) = -4*exp(-4), (2) = 12*exp(-4), (3) = -4*exp(-4)})

 

Download VC_Gradient_v.mw

@janhardo Note that it's better to re-use the general form if you want to find the gradient at many numeric points.

Suppose you want to compute the gradient at many numeric points. Don't use any method that calls the Gradient command each time, as that could be needlessly inefficient. Instead, compute the general form and then evaluate that at each of the numeric points. In other words, do the above asseparate tasks:

   gen_grad := Gradient(F,[x,y,z]):
   eval(gen_grad, Equate([x,y,z],[1,-1,2]));

The second of those can be done at multiple numeric points, but the first doesn't have to be recomputed.

@afernande1008 Stop adding duplicates of the preceding Comment as new Answers here.

@Preben Alsholm Yes, setting kernelopts(floatPi=false) avoids the issue because the instantiation doesn't induce an evalf right away. But the problem would still occur if the expression is evalf'd up front.

That is, this too crashes:

restart;
ee:=exp(-1.047197551*t)^8*
    JacobiTheta3(6.283185310*I*t+1.570796327,exp(-37.69911185*t))^8
    /exp(-.5235987758*t)^4
    /JacobiTheta3(3.141592654*I*t+1.570796327,exp(-18.84955592*t))^4:
plot(ee,t=0..4);

as does this, (which is what plotting attempts, unless the HFloat values for t are avoided via Digits or UseHardwareFloats settings)

restart;
ee:=exp(-1.047197551*t)^8*
    JacobiTheta3(6.283185310*I*t+1.570796327,exp(-37.69911185*t))^8
    /exp(-.5235987758*t)^4
    /JacobiTheta3(3.141592654*I*t+1.570796327,exp(-18.84955592*t))^4:
eval(ee,t=HFloat(.000657200628125));

[edit] I submitted a bug report.

Inside the adaptive plotter it attempts the following under evalhf , using the HFloat value (and that gets caught with an error). Then it falls back to attempting it with evalf.

restart;
ee := exp(-Pi*t/3)^8*JacobiTheta3(Pi*(4*I*t+1)/2,
        exp(-12*Pi*t))^8/(exp(-Pi*t/6)^4*
      JacobiTheta3(Pi*(2*I*t + 1)/2, exp(-6*Pi*t))^4):

eval(ee,t=.000657200628125);

                                    -5
       36176.36077 - 0.9893163422 10   I

eval(ee,t=HFloat(.000657200628125));
Execution stopped: Stack limit reached.

I'll guess that you've already noticed that it can be avoided by simplifying to JacobiTheta4, or raising Digits above 15, or setting UseHardwareFloats to false.

I wiĺl submit a bug report.

[edit] I also notice that it can be avoided by setting kernelopts(floatPi=false). So this does not crash for me:

ee:=exp(-Pi*t/3)^8*JacobiTheta3(Pi*(4*I*t+1)/2,
exp(-12*Pi*t))^8/(exp(-Pi*t/6)^4*
JacobiTheta3(Pi*(2*I*t + 1)/2, exp(-6*Pi*t))^4);
kernelopts(floatPi=false):
plot(ee,t=0..4);

Curiously, that kernelopts setting survives restart, in the GUI or the CommandLine Interface (I don't understand why floatPi and display_zero_complex_part persist after restart while assertlevel and opaquemodules do not.)

First 159 160 161 162 163 164 165 Last Page 161 of 592