acer

32328 Reputation

29 Badges

19 years, 317 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

I voted up this Answer because it makes two key points.

The first is the explanation about how the current result attains, including two relevant documentation citations.

The second is mention of appropriate commands for the query.

@Rotcev It's not clear to me whether you have fully understood my comments above. It matters, here.

I submitted a bug report for this yesterday.

[edit. I had also included C_R's example below.]

You can also get by here with,

   assuming positive

which is shorter still.

There are some others.

expr := (l*h*t*sqrt(4*k^2*a^2*t^2+m^2))
         /(sqrt(2*I*k*t*a+m)*sqrt(-2*I*k*t*a+m)*m):

 

simplify(evalc(expr)) assuming negative;

l*h*t/m

simplify(evalc(expr)) assuming positive;

l*h*t/m

simplify(evalc(expr)) assuming real, k*t*a<>0;

l*h*t/m

Download radical_simp_01.mw

But perhaps it's also mathematically true when a,k,t,m are real and m>0?

Your attachment was last saved using Maple 18.0.

When I run your attachment using Maple 18.02, it runs without error and produces a plot. CR-C_ac.mw

The inability to just use combine here is because the result automatically simplifies with the 2^(1/4) pulled out in front.

# This next output is the result of so-called
# automatic-simplification.
#
# That happens in the Maple engine, between parsing
# and evaluation. It cannot be prevented even by
# unevaluation quotes.

'(2*a*Pi)^(1/4)';

2^(1/4)*(Pi*a)^(1/4)

# It can be represented (and rendered as output)
# using the inert operator `%^` instead.

foo := (2*a*Pi)%^(1/4)

`%^`(2*Pi*a, 1/4)

InertForm:-Display(foo, ':-inert'=false);

0, "%1 is not a command in the %2 package", _Hold, Typesetting

value(foo);

2^(1/4)*(Pi*a)^(1/4)

Download autosimp01.mw

You can't have the expression in the form you want, unless it is in a special inert representation.

That special inert representation cannot be directly manipulated like the actual mathematical expression -- it can display as you'd like, but it then requires an extra action to turn it back into a programmatically usable form.

Do you need a way to programmatically construct the special inert call?

What exactly are these common ranges that you want to use as a common view, after calling your procedure multiple times?

@Scot Gould I submit bug reports on such examples of weakness in simplify. I sometimes forget to mention that in my answers, sorry.

Naturally, simplify attempts many kinds of thing. But it does so circumspectly -- trying to avoid potentially very expensive operations, and recursive calls back into itself, etc. It's a complicated subject.

Those calls like factor(combine(...)) came from an oracle program of mine. I didn't check that they were shortest, and now I know to plug a corner-case hole in which it didn't check. Thanks.

@Gabriel Barcellos If you read the Help page for the select command you will see that it also describes the highly related remove and selectremove commands.

For your B01 example, the select command can produce B011 the sum of your additive terms that contain the mentioned kind of trigh call.

The remove command can produce B011CONST the sum of terms that don't contain such.

And the selectremove command can produce both results, as a sequence of two items.

The second grouping in the Examples Section of that Help page uses has to select from a product of terms. Your example could use hastype (or has, if done right) to select or remove from a sum of terms. The idea is similar: for both a product or a sum the returned object is mostly the same kind of beast as the input.

Note that an empty product comes out as 1, while an empty sum comes out as 0.

Please put your close followup examples on this as Replies here, rather than in a wholly new Question thread.

Also, please either upload a .mw file attachment with your example input, or include it here in valid plaintext Maple notation. (Nobody should have to retype something from a mere image.) Thank you.

You can force that result using,

  simplify(combine(expr, symbolic))

But perhaps you are asking how to establish conditions under which it is true?

@C_R Sorry, I am not sure what you're trying to ask, because your previous example fails due to misspelling.

restart;

a := 2*Unit('m'):

InertForm:-MakeInert(a);

`%*`(2, `%Units:-Unit`(m))

with(InertForm):

MakeInert(a);

`%*`(2, `%Units:-Unit`(m))

Download sp01.mw

If it could be the case that your expression is just a single additive term, as opposed to a sum of more than one term, then you'd generally need to guard against that case rather than apply select directly.

restart;

 

# You probably don't want these.
# The `select` is differentiating amongst
# the multiplicands in the product, since
# the expression is not a sum.

expr := 3*m2*tanh(4*k+2*c);

select(hastype, expr, specfunc(tanh));

3*m2*tanh(4*k+2*c)

tanh(4*k+2*c)

expr := 3*m2^2/16;

select(hastype, expr, specfunc(tanh));

(3/16)*m2^2

1

Download prcase.mw

There are various workarounds:
- use an if..then..else to test whether expr is of type `+`, and
  if not then apply the hastype against the whole.
- Add some safe dummy (eg. __dum), to make the
  expression into a sum.

@jrive I wasn't trying to sound brusque, sorry. I was unsure b/c Carl had accidentally seen it differently.

FWIW, the words alone don't make it clear which of x1, x2, and (importantly) A are in the set of variables for which you want to solve. Naturally, the code you had, with {x1,x2} passed to solve, helped make that aspect clear.

Clear might be, say,
   solve the equations for x1 and x2 in terms of only DC, T, tau, and A.

Here are two ways. The first uses eq3 and eq4 as side-relations to simplify, and allow a "simplifying" substituion to get rid of ton and toff.

The second merely selects the two results you want -- for just x1 and x2 -- from my earlier suggestion's result.

restart

eq1 := x2 = x1+(A-x1)*(1-exp(-ton/tau))

eq2 := x1 = x2*exp(-toff/tau)

eq3 := T = ton+toff

NULL

eq4 := DC = ton/T

simplify(solve({eq1, eq2}, {x1, x2}), `~`[rhs = lhs]({eq3, eq4}))

{x1 = A*exp(T*(DC-1)/tau)*(exp(-DC*T/tau)-1)/(exp(T*(DC-1)/tau)*exp(-DC*T/tau)-1), x2 = A*(exp(-DC*T/tau)-1)/(exp(T*(DC-1)/tau)*exp(-DC*T/tau)-1)}

select(type, solve({eq1, eq2, eq3, eq4}, {toff, ton, x1, x2}), identical(x1, x2) = anything)

{x1 = A*exp(T*(DC-1)/tau)*(exp(-DC*T/tau)-1)/(exp(T*(DC-1)/tau)*exp(-DC*T/tau)-1), x2 = A*(exp(-DC*T/tau)-1)/(exp(T*(DC-1)/tau)*exp(-DC*T/tau)-1)}

NULL

Download dutycycle_ac.mw

@Carl Love Alas, the effective use of maxsols>1 with fsolve is (currently) restricted to a finite range.

This is crude timing below, showing mostly that it does work.

The subdivide methodology of univariate fsolve is similar to what Calculus1:-Roots(...,numeric) uses, via an internal `minimize/fsolve`. The basic idea is the same as your SubDivide: it's usually much better to split the task at found roots than it is to merely avoid them using the original range.

In general there can be difficulties preventing the undesirable finding of duplicates near the found-roots. Sometimes this can incur extra overhead, I suspect.

Shooting_method_ac.mw

(vote up, btw)

First 57 58 59 60 61 62 63 Last Page 59 of 591