acer

21433 Reputation

29 Badges

15 years, 114 days

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

See the Help page for mod, where it specifically explains how &^ differs from just ^.

n := 4142074788597595058238933087635402958555715420375128103710780511:
m := 65108105099101044032:
e := 3467995563410655813589059428902496618444213189544232426283402949:

m &^ e mod n;

     24733671999927750262610339317849962811213365592569778941953149

Specifically, that Help page says this:

     To compute i^n mod m where i is an integer, it is undesirable to
      use this "obvious" syntax because the powering will be performed
      first over the integers (possibly resulting in a very large integer)
      before reduction modulo m. Rather, the inert operator &^ should
      be used: i &^ n mod m.  In the latter form, the powering will be
      performed intelligently by the mod operation.

restart;
ig := sqrt(x)*sin(sqrt(3)*ln(x)/2):

H := int(ig,x):

A := simplify(subs(s=ln(x),
                   IntegrationTools:-Change(H, s=ln(x))));

  -1/6*x^(3/2)*(3^(1/2)*cos(1/2*3^(1/2)*ln(x))-3*sin(1/2*3^(1/2)*ln(x)))

simplify(diff(A, x) - ig);

                 0

That syntax error does not occur in 1D Maple Notation (plaintext) input, as of Maple 2019.0.

It still produces a syntax (parsing) error in 2D Input, in Maple 2020.1.

It was not discerning that the statement that precedes the local declaration is empty, and in consequence should not affect the validity of the syntax. It might be more clear to you if typed as follows:

proc(x)
  :
  local y;
  y:=x+1;
end proc;
Error, unexpected local declaration in procedure body

 

It's possible that this is an evaluation problem.

Instead of using those uneval quotes (single right-ticks) around the calls to the h procedure in the plotting attempt, try redefining the h procedure as follows.

h := proc(n)
   if not n::integer then return 'procname'(args); end if;

   ... whatever you had before ...

end proc

You could also try it as follows, using your original definition of h.

plot([n->h(floor(n))[1], n->h(floor(n))[2]], 1..10);

It's not very helpful to omit your definition of h, since that prevents us from testing.

(I leave aside efficiency concerns such as recalculation of h and adaptive plotting.)

Yes, this is a bug in solve (new in Maple 2020, but absent in Maple 2019 it seems). I shall submit a bug report.

The error appears when solve is called under assuming with the assumption on both _C1 and x. It seems to be related to the leading underscore on name _C1.

You can get around the reported error by doing it in two steps, eg.

restart;
A := -ln(u)/2 + ln(3*u - 2)/6:
B := _C1 + ln(x):
temp := A-B=0 assuming x::real, u::real, _C1::real:
solve(temp, u);

But there is something else strange and new going on for this example, even without assumptions or assuming. In Maple 2020.1, depending on the particular choice of names for the two parameters (ie. not the solved variable u) the result when passing solve the explicit option may be in terms of either explicit radicals or involve an implicit RootOf. In Maple 2019.2 passing the explicit option produced a result in terms of explicit radicals for this example, regardless of choice of names.

A reasonable guess is that this additional issue might be related to the lexicographic ordering of the three names in play. But it seems more complicated that that. See attached:
   solve_param_implicit.mw

Moreover, Maple 2019.2 produces the result with explicit radicals for your example even when solve is not passed the explicit option. So, if you are wanting the same explicit radical kind of solution as Maple 2019.2 produced then you might need to utilize allvalues in Maple 2020, since this additional issue isn't necessarily avoided by removing the leading underscore on the name.

Your first sentence queried as to why the error happens. It happens because the assuming facility has not yet been taught to not apply your blanket real assumption to the keyword option name evaluate_known_functions.

You can specify the assumed names -- a generally better idea, IMO, than using the blanket assumption.

restart;
expr:= ln(c^2*y/sqrt(c^2)+sqrt(c^2*y^2+1));

simplify(expr,size=true,evaluate_known_functions=false)
  assuming c::real, y::real;

Or you could programmatically generate the assumptions from the set of names present in the expression, or upon the set of names upon which the expression depends.

simplify(expr,size=true,evaluate_known_functions=false)
  assuming `::`~(indets(expr,And(name,Not(constant),satisfies(u->depends(expr,u)))),real)[];

`::`~(indets(expr,And(name,Not(constant),satisfies(u->depends(expr,u)))),real)[];

Kitonum's solution did a single integration (in terms of y), where the upper boundary was a single curve and the lower boundary was a single curve. But the formula for the upper curve involves solving the cubic, which makes it slightly more difficult to tell which parts of the explicit solutions are needed.

Another way is to do two integrations (in terms of x), where there are two curves for the lower boundary (piecewise over the relevant x domain), but the cubic need not be solved.

Even for the first approach I think that it is better to plot all three solutions to the cubic, in order to see which may be needed. The implicit plot doesn't really demonstrate that.

Plotting all the solved components, using legends and separate colors, can demonstrate just which parts of the explicit solutions are needed.

int_between.mw

I suspect that automation of the process would have a tendency to detract from the educational benefits of having to work out the challenging parts.

These work, where the key is first to combine the product of radicals.

restart;

check:=x-1/4*(2+2*(4*x^2+1)^(1/2))^(1/2)*(-2+2*(4*x^2+1)^(1/2))^(1/2):

simplify(combine(check)) assuming x>0;

             0

evala(combine(check)) assuming x>0;

             0

radnormal(combine(check)) assuming x>0;

             0

Here are two ways that you can show 12 plots (b-values versus other single column) in 2 columns and 6 rows.

ValeursB.mw

You can, of course, rearrange all or only some of those in some other way.

From your intial description it sounds as it you are looking for Maple's table data structure, which is an easy-to-use top-level command that produces a hashed map with simple indexing syntax and efficient augmentation.

(See also Chapter 4 of the Programming Guide.)

Another way is to use an initializer.

Eg,
        Vector(10, (i) -> 2+(6-2)*(i-1)/(10-1));

        Vector(N, (i) -> a+(b-a)*(i-1)/(N-1));

And naturally any of these techniques can be conveniently provided as terser functionality, by creating a custom re-usable procedure that accepts the relevant parameters.

When you finish manually rotating a 3D plot within a Plot Component you can get at the orientation angles by computation from the PROJECTION substructure. But you have to stop manual rotation, and then manually interact, to start that computation. (The angles can be recovered numerically from the 3x3 rotation matrix, stored in the first 9 entries of that substructure.)

But there is, alas, no "Action when Rotated" Property of Plot Components, akin to the Drag action Properties of 2D plots in Components. So you cannot get on-the-fly programmatic action as you rotate continuously.

I have requested that Property for Plot Components, some years ago. It might help if someone else who wanted it were to also submit the request.

It is missing possible simplification involving exp(x/2) and exp(x), eg. factoring, within the radical.

Here are two workarounds. The second is unfortunately more ad hoc.

restart;
ode:=diff(y(x),x)-y(x) = x*y(x)^(1/2):
ic:=y(0)=4:
sol:=dsolve([ode, ic],y(x)):

check:=odetest(sol,ode);

        4*x*exp(1/2*x)-2*x-x^2
        -x*(16*exp(x)-8*x*exp(1/2*x)+x^2-16*exp(1/2*x)+4*x+4)^(1/2)

simplify(eval(check,x=2*t)) assuming t>0;

                0

simplify(simplify(check, {exp(x)=exp(x/2)^2})) assuming x>0;

                0

Doing that last one in two steps shows an idea -- that the inside of the radical can be factored into a perfect square (and the rest from there it can handle).

simplify(check, {exp(x)=exp(x/2)^2});

    -x*(((x - 4*exp(1/2*x) + 2)^2)^(1/2) + x - 4*exp(1/2*x) + 2)

simplify(%) assuming x>0;

                0

If you mean the Embedded Component named TextArea then after insertion into your document you can change the number of visible rows and character-width in either of the following two ways:

1) Use the mouse-pointer, right-click and select "Component Properties" in the pop-up menu, and then adjust the two relevant properties: "Visible Character Width" and "Visible Rows".

2) By commands,  eg.
       DocumentTools:-SetProperty("TextArea0", ':-visibleCharacterWidth', 23);
       DocumentTools:-SetProperty("TextArea0", ':-visibleRows', 3);

See the Help page for more detail.

Note that the character-width relates to a fixed-width font, which cannot be directly changed. (Also, on Linux a variable-width font is used here, and so the component is always wider than designated by the Property.)

If you instead mean the Maplets element named TextBox then see its Help page.
 

[edited] I wrote this before the Question was edited to state that the OP stil wanted to manipulate the expressions. Why cannot the original form be manipulated and used for computation, while still handled by a special display command when needed? Does subsequent computation need to be able to distinguish structurally/programmatically between 1/expr and the desired expr^(-1) form, for each possible expr in the class? (If so, then better to have stated that too. If not, then what's wrong with a separate printing facility, used only on when showing output is needed?)

Try the following,

H:=e->subsindets(e,anything^negint,
                 u->InertForm:-Display(`%^`(op(u)),
                                       ':-inert'=false)):

raw := ztrans(beta*5^n*(n^2+3*n+1),n,z);
H(raw);

rat_poly_neg_pow.mw

You could also adjust that type, anything^negint. Are there non-polynomial symbolic denominators that you want to exclude from this treatment? The anything could be tightened up or amended.

Do you need the integer in the denominator to be handled in some way? (Eg, 1/5 typeset as a separate multiplicative factor, or as 5^(-1), etc...)

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