acer

32617 Reputation

29 Badges

20 years, 42 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@Honigmelone I got it to work without redefining everything. But using alist (or something done to it) rather than eval(alist,1) was key.

Unfortunately I'm away from a computer for two weeks, sorry.

@mmcdara Yes, using unapply can work here.

Did you mean   unapply('P'(i,1,1,x), x)  so that a procedure P doen't get its call evaluated there?

Using unapply is simpler. You may find it not easy to remember, but it's more convenient than applying subs to an anonymous procedure.

Using subs on a procedure is more powerful, but also more advanced.

That's a common dynamic: flexibility and power versus complexity of usage.

There are other ways, eg. codegen[makeproc] which has some additional kinds of generality.

What is the reason for using eval(alist,1) in the second argument passed to makeproc?

Your attempts to remove assumptions on x and y don't clear this.

hasassumptions(eval(alist,1));
                              true
about(eval(alist,1));
[x, y]:
  is used in the following assumed objects
  [x] assumed real
  [y] assumed real

The result of the implicitlot3d command has its computed data inside an ISOSURFACE call within the PLOT3D structure.

But that substrucure only contains the functional evaluations at all the 3-d points used (taken from the ranges). It does not contain the detail of specific points on the surface (eg, where the expression is zero). That is to say, the structure does not explicitly contain values where the surface lies.

The GUI plot renderer is computing/interpolating the displayed surface on-the-fly, using the values and sign-changes of that full data.

From the help page on Maple's plot structures,

  "The ISOSURFACE structure contains the samples of a function taken over a
   regular grid in 3-D space and is rendered as a 3-D surface approximating the
   zero surface of the function. TheISOSURFACE structure takes the form
   ISOSURFACE(A) where A is a four-dimensional Array. If you have an
   m-by-n-by-p grid, then A[i, j, k, 1..3] gives the (x, y, z) coordinates of grid
   point (i, j, k) and A[i, j, k, 4] is the function value at that point, for i in 1..m,
   j in 1..n and k in 1..p.  The Array A can be replaced by a list of m lists.
   Each sublist in turn contains n lists withp elements, each of which is a
   list [xijk, yijk, zijk, fijk], representing the (x, y, z) coordinates and the function
   value of grid point (i, j, k)."

So unless your other software can do the same computation to render a surface from that full 3-d grid of data then there's not much point in exporting it.

@Carl Love Some time ago I submitted a suggestion that the seq command be given an option to allow the user to specify the number of elements.

I did this because I get tired of writing things like seq(a+(i-1)*(b-a)/(N-1), i=1..N) . And it's error prone to have people remember that kind of syntax over and over. The analog of "fencepost" mistakes crops up.

The currently available optional 3rd parameter of the seq command (increment) doesn't make it less error prone, or much more convenient.  Eg, seq(a..b, (b-a)/(N-1))

The question is: how could this functionality be provided by the seq command? If it were to be a keyword option then what keyword would be good?

@nm I originally wrote it so that it (always) line-printed the result and then returned NULL, which is the default behavior of the stock latex command.

latex( 'sqrt'(x) + sin(x) );
 \sqrt{x}+\sin \left( x \right) 

lprint(%);
NULL

But here's a version that accepts options like the stock latex command. So, like the latex command it line-prints and returns NULL by default, but it also accepts the output option to optionally return a string.

restart;

 

aliasedlatex:=proc(e,
                   {output::identical(file,string,terminal):=':-terminal'})
local lookup, res;
lookup:=op(eval(alias:-ContentToGlobal));
res := :-latex(subs(lookup,e),':-output'=output,_rest);
if output=':-string' then
  return res;
else
  return NULL;
end if;
end proc:

 

alias(C[1]=_C1):

 

aliasedlatex(dsolve( diff(y(x),x)=1,y(x)) );

y \left( x \right) =x+C_{{1}}

 

 

aliasedlatex(dsolve( diff(y(x),x)=1,y(x)),
             output = string );

"y \left( x \right) =x+C_{{1}}"

(1)

 

Download alias_latex.mw

Of course that can be easily changed so that the default value for the keyword option output is string instead.  And, here, that default can be overridden to get terminal line-printing.

restart;

 

aliasedlatex:=proc(e,
                   {output::identical(file,string,terminal):=':-string'})
local lookup, res;
lookup:=op(eval(alias:-ContentToGlobal));
res := :-latex(subs(lookup,e),':-output'=output,_rest);
if output=':-string' then
  return res;
else
  return NULL;
end if;
end proc:

 

alias(C[1]=_C1):

 

aliasedlatex(dsolve( diff(y(x),x)=1,y(x)) );

"y \left( x \right) =x+C_{{1}}"

(1)

 

aliasedlatex(dsolve( diff(y(x),x)=1,y(x)),
             output = terminal );

y \left( x \right) =x+C_{{1}}

 

 

Download alias_latex_string.mw

 

 

Tell us the values of a,b,c,d, and e.

@tomleslie Various approaches, including Lagrange form interpolating polynomial, series solution (about x=0) via IVP reformulation, and Chebychev-Pade rational polynomial approximation.

restart;

de := sin(1)*(diff(y(x), x$2))+(1+cos(1)*x^2)*y(x) = -1:
cond := y(-1) = 0, y(1) = 0:

Digits:=15;
plist:=dsolve({cond, de}, y(x), numeric, output=listprocedure):
me:=dsolve({cond, de}, y(x), numeric, output=mesh)[2,1];

Digits := 15

 

Matrix(%id = 18446884398932593470)

(1)

 

CFy := CurveFitting:-PolynomialInterpolation(me[..,1..2],
                                             x,form=Lagrange):
degree(CFy,x);

14

(2)

P:=Student:-NumericalAnalysis:-PolynomialInterpolation(convert(me[..,1..2],
                                                               listlist),
                                                       method=lagrange):

NAy:=Student:-NumericalAnalysis:-Interpolant(P,independentvar=x):
degree(NAy,x);

14

(3)

sort(fnormal(expand(CFy-NAy)));

0.

(4)

Y:=eval(y(x),plist):

plot([abs(Y(x)-CFy)], x=-1..1, size=[600,200], view=0..1e-8);

 

plot([abs(Y(x)-NAy)], x=-1..1, size=[600,200], view=0..1e-8);

 

TLsol:=dsolve({de,cond}, numeric):
Order:=15:
TLy:=sort(evalf(rhs(convert(
             dsolve({de,
                     y(0)=rhs(TLsol(0)[2]),
                     D(y)(0)=rhs(TLsol(0)[3])},
                     y(x), 'series'), polynom)))):
degree(TLy,x);

14

(5)

plot([abs(Y(x)-TLy)], x=-1..1, size=[600,200], view=0..1e-8);

 

CPy:=eval(numapprox[chebpade](eval(y(x),plist)(x),
                              x=-1..1,[14,1]),T=orthopoly[T]):
degree(CPy,x);

14

(6)

plot([abs(Y(x)-CPy)], x=-1..1, size=[600,200], view=0..1e-8);

 

 

 


Download bvp_interp.mw

@ligonberry 

I don't recall an earlier question where someone asked for the explicit interpolant for a BVP.

I should ask why you want to get such a thing, assuming I'm interpreting you rightly. Is it for export, to be used in another program? If not then why do you want it?

There would be few reasons to want it if you're just going to be operating in Maple itself. The procedure returned by dsolve(...,numeric) is designed to utilize the computed mesh of interpolation points efficiently, on demand when given specific numeric input for the independent variable.

How would you feel about, say, an explicit symbolic interpolant constructed from the data returned by supplying the output=mesh option for dsolve(...,numeric)?

IIRC the usual procedure returned by dsolve(...numeric) for BVPs will itself call internals like `dsolve/numeric/lagrange` or `dsolve/numeric/hermite`, to efficiently generate the solution at a queried numeric point. Perhaps we could construct the explicit interpolant based on this usage.

@ligonberry Mariusz gave you Maple code which solves it numerically, as the first 5 lines of dark text in his Answer.

@Adam Ledger You are wrong when you claim,

   "Also because it is a simplification that is concealed in an inner level of
    abstraction of evalf, i need to know the showstat for evalf so that I can
    further understand the causation of the invalid computation"

The exact result from simplify is not correct. It's already wrong before it gets into evalf. You don't need to see the inner workings of evalf to figure out the cause of the discrepency. It's a branch-cut problem related to simplify, not a problem in computing to floating-point under evalf.

Here, simplify is behaving as if it's not taking into account that LambertW(1,Z) might not be real.

@Adam Ledger I shortened the example to try and illustrate more succinctly that the difference is due to an invalid simplification.

@SGJanssens Is there an attachment?

I'm not against a Post, if you have results to share. (You could also Branch off a Post as well.)

Please stop converting this from Question to Post, whoever is doing so.

G := tanh(h)^(1/2)*(exp(4*h)-1)^(1/2)*exp(-h)+exp(h)-exp(-h):

solve( G, [h] );   # ouch
                      [[h = h]]
First 252 253 254 255 256 257 258 Last Page 254 of 596