Carl Love

Carl Love

19627 Reputation

24 Badges

8 years, 44 days
Mt Laurel, New Jersey, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

Both the commands plot() and plot([]) produce an empty plot with no warning. So the following procedure does what you describe:

MyPlot:= proc(X::list(realcons), f)
local x, n:= nops(X);
    plot(( 
        if n = 1 then 
            [[X[], f(X[])]], style= point, symbolsize= 20
        elif n > 1 then 
            CurveFitting:-Spline(X, f~(X), x), x= (min..max)(X)
        else
        fi), _rest
    )
end proc
:
MyPlot([1,2,3], sin);

I may need to adjust that for earlier versions of Maple.

I think that you may have the idea that you first define an empty plot, and then add things (like points or spline curves) to it. The plot command doesn't support such object-oriented methods, although it would be possible to implement something like that.

The situation with W1 and W2 is clear, and it'll be better handled by piecewise than by if:

W1:= h-> piecewise(h < 1, 1, 2);
W2:= h-> piecewise(h < 1, 3, 4);

Within the main function, use W1(h) and W2(h).

But how are tN, and h_TOT handled?

There are many ways to do it, here's one:

for i to 9 while F[i]+F[i+1] < 20 do od;

print(`if`(i > 9, Testbestanden, Durchgefallen));

Notes:

  1. od is the same as end do. It's just a personal choice.
  2. This loop has no statement in its body (or you could say it has the null statement). That's not a problem. 
  3. We need to know why the loop terminated. If i > 9, it finished normally; otherwise the while condition failed for some i.
  4. `if` can be used as a function using the syntax shown. The quotes are mandatory.

Sets are automatically sorted when they are created in a way that is most efficient for lookups. Indeed there is no way to prevent this sorting. 

You should store your 30-digit numbers as integers, so that they'll fit into two 64-bit words.

There's no need to directly use membership testing. Just take intersections of X with subsets of Y until a nonempty intersection is obtained or Y is exhausted. 

I suspect that you actually typed "4(4x^2 - y^2)" and not "4*(4*x^2 - y^2)" because if you had typed the former, Maple would've intentionally responded exactly the way that you say it did respond. 

If you're using 2D Input, you can use a space instead of *, but putting a number immediately to the left of another expression will never work.

I'm impressed that you already realize that there must be a more-elegant way. One such way, which is widely used (because it vastly improves the readability of one's work), is to never make direct assignments to the low-level variables such as Q. I suspect that you can already see that the solution to your question would've been easy if Q hadn't been assigned. 

Now, if I don't include this paragraph, some nitpicker is nearly certain to point out a method that let's you make the assignment to Q and later remove it. Yeah, that "works" in the sense that Maple will understand it, but it even further degrades the readability of your work.

You know my opinion about the whole "match" family of commands: They're ancient half-implemented ideas that should've been deprecated years ago. In almost all cases, the same thing can be accomplished much more easily and much more efficiently with other commands. This one is an especially easy case: 

IC:= (ic::(function(name)=algebraic)) -> op~([[1,0..1], 2], ic)

 

 

The first thing I'd try: Get rid of all assumptions: those in assumeadditionally​​​​​, and assuming. Discard the real assumptions entirely; they're redundant anyway because they're implied by the inequalities. Put all the inequalities that were in assumptions directly in the first argument of solve. Since all your expressions are rational functions with rational coefficients, I think that that's guaranteed to work (at least in recent Maple). A more-sophistcated piecewise solution can usually be obtained using the keyword 'parametric' as a third argument to solve.

There is also a useassumptions option to solve, but I think that using it is always equivalent to what I described above. For one thing, the only assumptions that it processes are inequalities. Without the use of this option, it's definitely ignoring your assumptions. 

Once again, I haven't tested this on your system because I'm traveling. 

Let's suppose that the expression containing radicals is ex. Then do

rads:= (op~(1, indets(ex, algebraic^fraction)) >~ 0)[];

I'm traveling and posting from my phone, so I haven't tested this.

When I want to do this, I usually want the most maximally unsmooth gradation possible that's still easily recognizable as a representation of a numeric continuum. I think that the following gives something pretty close to that. This can also be easily done with Gradient, but I had been doing it this way since many years before ColorTools existed. Note that the only significant line in the procedure below is the color= ...; the rest is just to give it something (inane) to plot.

Stripes:= proc(N::And(posint, Not(1)))
local k;
    plot(
        [seq]([[0,k/N], [1,k/N]],  k= 1..N),
        color= [seq](COLOR(HSV, .87*(k-1)/(N-1), 1, 1), k= 1..N),
        thickness= 5
    )
end proc
:   
Stripes(29);

 

If the fudge factor .87 is omitted, then the colors cycle from red back to red.

While I recommend that you use Gradient as acer suggests, the reason that you got 19 instead of 10 is simple and has nothing to do with colors. The option numpoints= N to plot means to use at least N points unless you also give option adaptive= false, which'll make it exactly N.

For any y in your interval of interest (which appears to be lambda(0)..lambda(1)), the equation lambda(x) = y can be explicitly solved for x. This is because lambda(x) can be expressed as a composition of two functions lambda(x) = g(f(x)) where g(z) is a 4th-degree polynomial and f(x) = 1/(1+x^2/2) = 2/(x^2+2)

#This is your expression for lambda (copied directly from your worksheet):
lambda:= x-> -1/20*(3*(-1)*6.003*(1 + 1/2*x^2)^3 + 
    3*15.400672*(1 + 1/2*x^2)^2 + 
    3*(-8.745236204) + 
    3*(-1)*7.393580208*x^2)/(1 + 1/2*x^2)^4:

#I extracted these two coefficients from that expression:
a:= 7.393580208:  b:= 8.745236204:

f:= x-> 1/(1+x^2/2):
g:= unapply(3/20*(6.003*z - 15.400672*z^2 + 2*a*z^3 - (2*a-b)*z^4), z);

#Confirm that g(f(x)) = lambda(x) (upto floating rounding error):
simplify(g(f(x)) - lambda(x));
        -1.*10^(-8)/(x^2 + 2.)^4

#Invert g explicitly:
G:= solve(g(z) - y, z, explicit):
#Invert f explicitly:
F:= solve(f(x)-y, x, explicit):

#G has 4 branches, and F has 2. With a bit of experimentation (not shown,
#but there's only 8 possible combinations) I discovered that the 3rd branch of G and
#1st branch of F are the ones that we want:
Lambda_inverse:= unapply(F[1], y)@unapply(G[3], y):

#A simple plot confirms that this is the correct inverse:
plots:-display(
    plot(lambda, 0..1, color= red,  legend= lambda), 
    plot(Lambda_inverse, lambda(0)..lambda(1), color= green, legend= inverse)
);

Check the residuals:

plots:-display(
    plot((Lambda_inverse@lambda)(x) - x, x= 0..1, color= red),
    plot((lambda@Lambda_inverse)(y) - y, y= lambda(0)..lambda(1), color= green),
    axes= boxed
);

If you still want a polynomial approximation for the inverse, you can simply use its Taylor series:

convert(series(Lambda_inverse(y), y= lambda(.5)), polynom);

0.6679588030 + 5.115695847*y - 0.085616168*(y + 0.03283205376)^2 + 132.3063112*(y + 0.03283205376)^3 - 742.9280343*(y + 0.03283205376)^4 + 10257.45347*(y + 0.03283205376)^5

This will give you a better polynomial than the technique you proposed. Degree-5 is default, but you can use a 3rd argument to series to get any degree that you want. (Even if it weren't possible to explicitly invert lambda, it would still be possible to generate the Taylor series of its inverse.)

Given the simplicity of your 2nd ODE, it's obvious by integrating that y(t) = 1 - t^2/2 + int(x(tau), tau) where the 1 and the (implied) 0 constants of integration come from the initial conditions. Visual inspection of the two series confirms that this formula is correct. I'm sorry that I can't figure out (at the moment at least) a way to get Maple to perform this automatically.

@Maple_lover1 

Q1: Is there any difference between w:= x-> 1 and w:= (x)-> 1?

Ans: No. If a function has a single parameter, and there's no type declaration (such as (x::algebraic)-> 1), then the parentheses can be omitted.
 

Q2: Is there any difference between unapply(..., [n, m, x]) and unapply(..., n, m, x)?

Ans: The end results are identical. My guess is that the first of these incurs a very very slight performance penalty, but only in the unapply step itself, not in the final function returned, due to the need to garbage collect the list. My personal preference is unapply(..., (n, m, x)), which indicates to a human reader the logical grouping of the three parameters, but in a purely syntactic way; the unapply command will not even receive these extra parentheses, let alone need to process them. Superfluous parentheses, such as these, are stripped off when the code is saved.


Q3: How to use orthopoly with the uses declaration?

Ans: There are two formal types of "packages": module-based and table-based. Table-based packages are very old, pre-Maple 6 (year 2000), and even most of those have since been converted to module-based, or at least module-compatible. Apparently orthopoly has not. The uses declaration seems to object to this, and perhaps that should be considered a bug. But you can do this:

    uses O= orthopoly; #O can be any symbol of your choice.
    
...
    ... O:-H(m, 2^k*x-2*n+1)  ...

This is my preferred syntax for any package used within a procedure or module. It involves a little bit more typing, but when someone reads that code in the future, they'll never have any question where comes from.

By the way, your procedures FunctionAFunctionB, and FunctionC all have a parameter M which seems to be never used. Surely this is a coding error. I think that you already know that uppercase and lowercase give distinct variable names.

Another error (at least a very likely potential error) is that you need to do something to guarantee that the nm, and are of type symbol. The most-appropriate thing would be to make them local to FunctionC, etc.

You should never use the with command in a procedure, module, or package. It just doesn't work as you'd expect. Instead, explicitly use the package name prefix or use a uses declaration. 

I'm not sure whether this is the only error in your code. I simply stopped reading as soon as I saw with (because I'm pressed for time at the moment).

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