acer

22182 Reputation

29 Badges

15 years, 230 days

Social Networks and Content at Maplesoft.com

"My friend George Mallory… once did an inexplicable climb on Snowdon. He had left his pipe on a ledge, half-way down one of the Liwedd precipices, and scrambled back by a short cut to retrieve it, then up again by the same route. No one saw what route he took, but when they came to examine it the next day for official record, they found an overhang nearly all the way. By a rule of the Climbers' Club, climbs are never named in honour of their inventors, but only describe natural features. An exception was made here. The climb was recorded as follows: 'Mallory's Pipe, a variation on route 2; see adjoining map. This climb is totally impossible. It has been performed once, in failing light, by Mr G. H. L. Mallory.'." -- "Goodbye to All That", Robert Graves

MaplePrimes Activity


These are answers submitted by acer

A usual Worksheet/Document "table" is not really a programmatically accessible structure, so there is no easy way to use its cells for data.

But there is an alternative DataTable embedded component, which makes its entries be immediately accessible programmatical since its entries are stored in an rtable (eg. Matrix).

Do you need an example, or would you prefer to look at its Help page examples first? You can also look at its Help page in Maple's own offline Help facility.

If you have a program or procedure then it's more common to approach this from the other direction, ie. programmatically construct Matrix/Array/Vector of the data and then 1) plot directly using those, and 2) display the computed data in some tabulated format using printf or Tabulate.

With your choices for gridrefine, crossingrefine, numpoints, rational, etc, you can still suppress the line through the additional signchange=false option.

The signchange=false option instructs implicitplot to exclude points on the line x=-mu across which F1 changes sign without attaining zero.

It's not clear whether you bumped all those options as attempt to fix your issue, or for some other reason. Perhaps you actually have some other example, since this one can be solved explicitly and plotted much more efficiently with the plot command and its discont option.

I decreased the very extreme gridrefine and crossingrefine from 15 to 3, which would still exhibit the line without signchange=false. But at 15 a great deal of work is done for practically no benefit.

restart;
F1:=1/(x + mu) + x - 1:

plots:-implicitplot(F1 = 0, mu = -8 .. 8, x = -4 .. 4,
                    color = blue, thickness = 2, rangeasview,
                    gridrefine = 3, crossingrefine = 3, rational,
                    signchange=false,
                    numpoints = 100000, resolution = 3000);

plot([solve(F1,mu),x, x=-4..4], discont, view=[-8..8,-4..4],
     color=blue, thickness = 2, labels=[mu,x]);

impl_signchange.mw

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
5 6 7 8 9 10 11 Last Page 7 of 247