acer

30360 Reputation

29 Badges

18 years, 260 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

It seems to be a consequence of the new (Maple 2022) default for the adaptive option. That behaves like adaptive=geometric here.

If you force (the old default of) adaptive=true then that artefact doesn't appear.


ps. In Maple 2021.2 you can reproduce the artefact for this example, by suppling a (now defunct) variant of that option (then-undocumented), adaptive=plotthing
pps. For this example I am not seeing that artefact when using a Beta version under development.

lst := [`A=70`, `B=17`, `C=27`, `D=37`, `E=74`, `F=57`, `G=67`, `H=08`,
        `I=81`, `J=28`, `K=38`, `L=48`, `M=58`, `N=68`, `O=90`, `P=19`,
        `Q=29`, `R=39`, `S=49`, `T=59`, `U=96`, `V=010`, `W=110`, `X=210`,
        `Y=310`, `Z=410`, "SPACE=105", "DOT=106"]:

tt := table(parse~(lst));

For some reason the typesetting system is going awry on 2D Output display of the series structure returned by the taylor command. The computation might proceed, even if you cannot print that structure.

It appears to print ok if you convert that series structure to a polynom (which I expect you'd probably want to do anyway).

maple_primes_question_ac2.mw

I don't really understand your goal with indefinite integration here.

Is this the kind of effect you're after?

Q_2024-02-15_Help_Spread_diagram_ac.mw

Note that the lowercase typeset you were using is not an export of the Typesetting package. (Though Typeset is.) So merely loading Typesetting has no effect, because nothing different gets called.

However if you were to instead replace that lowercase typeset with Typesetting:-Typeset then you'd get the effect of the infix `.`, however it would render in gray not black because you're using the inert %. .

The Display command from the InertForm package does allow you to get the infix %. calls with the dot rendered in black (while also typesetting it all to some MathML-like form).

You could also use the operator-form calling sequence of Int.

Sometimes I use that instead of conditionally returning 'procname'(...) because the syntax is simple. Also, it can still let the integrand be evalhf'ble which sometimes (but not always) makes a speed difference.

However using operator form can get tricky if there are nested Int calls that cannot/shouldn't be collapsed. Then the approach of conditionally returning unevaluated is very useful. And the procedure z could itself call evalhf, so that aspect is not a barrier.

Stuffing in uneval-quotes is my least favored approach. They are ephemeral. Ostensibly simple adjustments to the approach can break due to some overlooked extra evaluation which strips off a pair of such quotes. If you're lucky you get a thrown error when that happens, and if unlucky a wrong result. It is the least robust approach.

restart;
J1 := proc()
  local z:
  z := proc(u) local x; fsolve(sqrt(x)=u, x) end proc:
  evalf(Int(z, 0..1))
end proc:
J1(); # 0.3333333333

.3333333333

restart;
J2 := proc()
  local z:
   z := proc(q1, q2) local x;
     exp(
       2*(
         fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = q1, x)
         *
         fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = q2, x)
       )
       -
       fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = sqrt(q1), x)^2
       -
       fsolve(1/2+(1/2)*erf((1/2)*x*sqrt(2)) = sqrt(q2), x)^2
    )
  end proc:
  evalf(Int(z, [0.1..0.9, 0.1..0.9]))
end proc:

CodeTools:-Usage(J2());

memory used=2.35GiB, alloc change=68.00MiB, cpu time=22.24s, real time=22.02s, gc time=1.04s

.4412675858

Download Int_uneval_ex.mw

ps. On a separate note, these procedures z use the name x as a variable of integration. I suggest that you declare that as a local, to avoid collision with x possibly defined at a higher level. Or you could operator-form calling sequence for fsolve.

In your example the expression assigned to y involves the call g(x). So you could prevent f(x) from evaluating to F(x) when you substitute f for g.

Or you could also substitute (f@@(-1))=(F@@(-1)) .

Or you could instead substitute g for f, since g is unassigned in your example

restart;

f := x -> F(x);

proc (x) options operator, arrow; F(x) end proc

y := ((f@@(-1))@g)(x);

(f@@(-1))(g(x))

lprint(y);

(f@@(-1))(g(x))

eval(y, g=''f'');

x

subs[eval](g=''f'', y);

x

eval(y, [g=f, (f@@(-1))=(F@@(-1))]);

x

eval(y, f=g);

x

subs[eval](f=g, y);

x

Download inv_eval_ex.mw

Certainly you wouldn't want those complicated conditionals repeated over and over.

Some code that processes the alternates and gets a canonical form (one of your "Red", "Green", or "Blue") can be a way to deal with this. Then you only need to hard-code the alternates in that single place.

One common approach is to do that processing at the start of the procedure body. Then assign the result of that to some local name. And then reference that local instead of the parameter name, throughout the procedure. (I expect that you already know that you could do that. It's not slick or super convenient to write, but it works.)

But quite a few flavours on this theme could also be handled by using the coercion parameter modifier.

Here an example that also allows other mixed upper/lower case spellings. (You could tighten that up to just your original, if you wanted...)

restart;

 

p := proc(c::coerce(proc(s::string)
                      local L:=StringTools:-LowerCase(s);
                      piecewise(member(L,["blue","b"]),"Blue",
                                member(L,["green","g"]),"Green",
                                member(L,["red","r"]),"Red","Blue")
                    end proc):="Blue")

  return c;

end proc:

 

p("bLUe"), p("Blue"), p("blue"), p("b"), p("B");

"Blue", "Blue", "Blue", "Blue", "Blue"

p("ReD"), p("Red"), p("red"), p("r"), p("R");

"Red", "Red", "Red", "Red", "Red"

p("GreEn"), p("Green"), p("green"), p("g"), p("G");

"Green", "Green", "Green", "Green", "Green"

Download coercion_ex.mw

There are several behaviorally different variants on that. I don't know how you might want additional arguments handled, if they don't match at all. I don't know if you'd want it to throw an error, or return "Blue", or pass it over, etc. Some extra juice can be wrung out, according to whether you make the param-specification of s be tighter, or do something else as the default value of the piecewise, etc.

note: you might not be able to make such a coerced parameter be treated completely like an optional ordered parameter (in the sense of skipping over arguments). It may absorb an argument. That might be ok for your purposes.

The re-usable part, that you've called a "script", can be implemented in Maple as a user-defined procedure.

Afleiding_Euler_knik_2_staven_inc_rotveerRev_3_ingekort_mapleprimes_ac.mw

You may use the numapprox package to construct a rational polynomial that approximates your f (up until its slope gets acceptably small...).

We can start from a small positive value, since not everything here behaves so nicely at x=0 exactly.

I did not raise Digits here. If you plan on exporting the resulting expression into some external application that can handle float double-precision (eg. compiled code) then you could try setting Digits:=15 and see if better accuracy attains (depending on degrees requested).

restart

f := proc (Gamma) options operator, arrow; RootOf(8*_Z^4+12*Gamma*_Z^3+(5*Gamma^2-4)*_Z^2-4*Gamma*_Z-Gamma^2) end proc

cutoff := fsolve((D(f))(x) = -0.1e-2, x = 0 .. 20)

12.39859048

numapprox:-chebpade('f(x)', x = 0.1e-12 .. cutoff, [7, 0]); fapprox := numapprox:-confracform(eval(%, T = orthopoly[T]), x)

-0.5132980022e-6*x^7+0.2538176566e-4*x^6-0.5130976487e-3*x^5+0.5470836089e-2*x^4-0.3320108938e-1*x^3+.1162273184*x^2-.2312134649*x+.7051773552

evalf(f(0.1e-9)); eval(fapprox, x = 0.1e-9)

HFloat(0.7071067811615476)

.7051773552

select(type, [allvalues((D(f))(0.1e-9))], realcons); evalf((D(f))(0.1e-9))

[-.2500000001, -.2499999997]

HFloat(-0.2499999999734836)

plot([f(x), fapprox], x = 0.1e-9 .. cutoff, size = [400, 200], style = [line, point], adaptive = false, numpoints = 30)

Download approx_ac.mw

Above I requested chebpade construct a polynomial (degree in denominator as zero). Often one can do better with a rational polynomial. There are also other commands in the numapprox package which might be useful to you, depending upon your example and target criteria.

restart

f := proc (Gamma) options operator, arrow; RootOf(8*_Z^4+12*Gamma*_Z^3+(5*Gamma^2-4)*_Z^2-4*Gamma*_Z-Gamma^2) end proc

cutoff := fsolve((D(f))(x) = -0.1e-2, x = 0 .. 20)

12.39859048

numapprox:-chebpade('f(x)', x = 0.1e-12 .. cutoff, [4, 4]); fapprox := numapprox:-confracform(eval(%, T = orthopoly[T])); lprint(%)

.4472136520+.1599975720/(x+.2233429806+.2284057047/(x+.2453840484+.4526625636e-\
1/(x-7.849960113+75.61933337/(x+9.470962330))))

evalf(f(0.1e-9)); eval(fapprox, x = 0.1e-9)

HFloat(0.7071067811615476)

.7071086039

select(type, [allvalues((D(f))(0.1e-9))], realcons); evalf((D(f))(0.1e-9))

[-.2500000001, -.2499999997]

HFloat(-0.2499999999734836)

Download approx_ac2.mw

[edit] I gave this answer because of the following preceding detail from the OP. Up until this time there had been no mention by the OP of obtaining good asymptotic matching. As described below the posed problem had been about getting an accurate match up until some cutoff value:

"Let's say I still wanted to obtain an approximation for f(Gamma) for Gamma from 0 to that Gamma sending f(Gamma) relatively close to sqrt(5)/5...Such approximate polynomial should be a very simple (no more than one line) function of Gamma that well captures its original shape up to the point it starts stabilizing at sqrt(5)/5 (very roughly at which Gamma?). How would you do this?"

The goal of obtaining matching asymptotic behavior (as x tended to infinity), which can involve quite different methodology, was only agreed with later by the OP.

You have not shown us any definition of (or assignment to) xA||i and yA||i for i=1..6. You should explain that.

restart;

with(LinearAlgebra):

xA := 1: yA := 0: xB := 0: yB := 0: xC := 0: yC := 1:

Mat := Matrix(3,3,[xA,xB,xC,yA,yB,yC,1,1,1]):

phi:=unapply(LinearSolve(Mat,<x,y,1>)^%T,[x,y]):

phi(-3,2);

Vector[row](3, {(1) = -3, (2) = 2, (3) = 2})

phi(4,-5);

Vector[row](3, {(1) = 4, (2) = 2, (3) = -5})

phi(8,-7/2);

Vector[row](3, {(1) = 8, (2) = -7/2, (3) = -7/2})

Download LA_Jamet_ex.mw

The cost of the overhead of wrapping an expression sequence in square brackets -- obtaining a list -- is small.

And then you can use either numelems or nops.

S := StringTools:-SearchAll("aba", "abababababababababab");

1, 3, 5, 7, 9, 11, 13, 15, 17

numelems([S]);

9

nops([S]);

9

Download numelems_seq_list.mw

When none of your piecewise conditions holds it will evaluate to its default value, which by default is zero. That collides with your goal of asking implicitplot to find where it is zero.

You can pass an additional argument to the piecewise command, as some alternative default value.

restart;

g := piecewise(0 <= x and x < 33, -50*x + 33*y,
               33 <= x and 38.78 < y, (x - 47.94)^2 + (y - 40.55)^2 - 312.36,
               58 <= x and x < 100 and 0 <= y and y <= 38.78,
               0.5778*x^2 - 66.08774*x - y + 1887.9165,
               undefined):

plots:-implicitplot(g, x = 0 .. 80, y = 0 .. 60, scaling = constrained)

Download pw_def_impl.mw

Is this the kind of effect you are after?

You could also adjust the granularity factor (below, 50). You could also make it match or multiple what you could pass for the frames option of the animate command (not done below).

You can remove the caption, naturally.

restart;

st:=[ -137, 74, -2]:
final:=[180,0,180]:

P:=plot3d(10^10/E*T, E = 0 .. 1000000, T = 0 .. 15,
          labels = ["E in (EUR)", "T (in Jahren)", "V (in EUR)"],
          view = 0 .. 180000, labelfont = [times, bold, 12],
          orientation=st):

f := (n,N)->st+n*(final-st)/N:

plots:-animate(plots:-display,
              [P,orientation=f(n,50),
               caption=typeset(evalf[3](f(n,50)))],
               n=1..50, paraminfo=false);

Download anim_ex2.mw

If you want the rotation to take some other route then please describe it explicitly.

Your methodology of trying to assign numeric values to delta as well as delta(m) is flawed.

Try changing the solitary delta instances to Delta.  Or make all the delta(m) into say deltam.

First 8 9 10 11 12 13 14 Last Page 10 of 316