Carl Love

Carl Love

27666 Reputation

25 Badges

12 years, 131 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@mehran rajabi 

Firstly, this was stated by others, but I want to restate it more adamantly than they did: This is a linear differential equation, not a nonlinear one. 

Extracting the coeffiecients in this case requires not only the PDEtools:-dcoeffs suggested by @ecterrab but also the command content to get rid of the x parts:

ode:= 
    c1*diff(f(x),x$4) + c2*diff(f(x),x$3)/x +
    c3*diff(f(x),x$2)/x^2 + c4*diff(f(x),x)/x^3 + c5*f(x)
:
content~([PDEtools:-dcoeffs](ode, f(x)), x);

                     
[c1, c2, c3, c4, c5]

Note that I've entered ode not as an equation but as an expression implicitly equated to 0. Most Maple commands do not force you to use one or the other; however, dcoeffs requires the latter.

@acer Geez, I was looking through package ContextMenu for over an hour trying to answer this Question, and you're saying (essentially) that that package isn't being used? For example, I tried

P:= plot(x^2, x= 0..1):
ContextMenu:-Test:-ListMenuEntries(P);

That listed 241 menus in plaintext form, none of which seemed relevant, and the majority of which had nothing to do with plots. Since the context menu for a 2-D plot has an entry for a submenu named "Axes", I was searching the output of various ContextMenu commands for the string "Axes", but I never found it.

How can one use this package in this "context"?

@ecterrab Thanks. I was totally unaware of the dsolve syntax that uses [f, {...}] as the second argument.

@nm You wrote:

  • I do not want to add code to keep checking if m and n are type numeric just to avoid using is and to  just normal n<=m just to save few nano seconds.

I'm not suggesting that you do a type check for numeric. In the vast majority of cases, I know a priori (meaning, at the time that the code is written) that both sides are numeric. Your example of using a type check to decide between the two is, of course, ridiculous, and I would never suggest doing that.

  • So I think using is all the time makes the code simpler, as it works in both cases. Right?

No. There's a small chance that is will take a very long time, perhaps get stuck, perhaps return FAIL. The default boolean evaluation would never do any of those things, but is is a house built on sand. It's a weak command IMO. You're suggesting changing every Boolean condition in all your code to is. You batch process thousands of cases at a time, right? Do you really want to add thousands of instances of the use of a command that has even a small possibility of getting stuck? I suggest that you only use is in those cases where one of the sides might be non-numeric. If you're saying that that's all your cases of using an inequality with if in all your code, then I don't believe you. If, on the other hand, you actually mean changing all the cases in a few large programs, then I believe you.

@nm I just substantially updated my Answer to address some of those issues.

I can easily eliminate one of your three boolean evaluators: Since if a <= b does exactly the same thing as if evalb(a <= b), there's no need for the latter. evalb is only needed when an inequality (or other relation) is used in a context that doesn't automatically imply that it needs to be reduced to true or false (or FAIL, depending on the context).

I don't think that you should change all your code from evalb to is! Only do the cases where you're not sure that both sides are type numeric.

Should an unsolicited link for another CAS be considered spam? I lean towards "No", but I'm unsure. I think the OP should post some examples of what there CAS can do.

@Carl Love I just updated the code above, making it significantly faster in the case that the number of desired small divisors is large, yet still a small fraction of the total number of divisors. This is shown in the last example in the worksheet.

@felixiao Obviously there is a pattern to all the matrices, T11 to T36. You need to discover the pattern, then abstract it and generalize it into a procedure. You should be able to make a procedure of about10 lines that constructs all the matrices.

Your code is extremely unwieldy. It needs to be divided into several execution groups, or procedures. Using 2D Input also makes it difficult.

@felixiao It can be done with seq loops like this:

HH||(0..2):= 
    seq(H||(1+(k mod 3)).H||(1+(k+1 mod 3))^(-1), k= 0..2)
;
TH:= proc(i) local k;
    `.`(seq(T||(i+2*k)^(-1).HH||k.T||(i+2*k+1), k= 0..2))
end proc
:
TH(11).TH(21).Y;

 

@felixiao I'm trying to understand the pattern of the new product that you want. I don't understand why there's no T17 to T21.

I'm using Windows 11. Axel is using Windows 7, so maybe the bug doesn't exist in Windows 7. I changed your 40 to 100 and I also got a hang.

I agree with you that this is one of the two worst bugs in Maple. The other contender is the disappearing menus and toolbars since Maple 2021. The timelimit bug makes it nearly impossible to effectively run things in "batch mode"; the menus and toolbars bug makes it very difficult to work in non-batch mode with worksheets and/or documents (the bug is active regardless of whether you use 1D or 2D input). I think that 1 top programmer (1 for each) should be assigned to work full time on these until they are fixed.

A reasonable alternative to the current timelimit command would be a timelimit[real] command. Perhaps that would be easier to implement.

@nm Thank you for testing. I'll say again that I don't intend for this SubsIndets to be used in practice. Rather, it's purpose is to teach how subsindets works.

@nm I just realized that there's a remote possibility that if f returns NULL, and this NULL is substituted into the future list entries, then some of those future entries might become NULL also. Since NULL can't be a list element, this could cause a problem. Thus, I change my SubsIndets to

SubsIndets:= proc(e, T::type, f)
local X:= [sort([indets(e,T)[]], key= length)[], e];
    while nops(X)>1 do X:= subs(X[1]= f(X[1]), X[2..]) od;
    X[-1..][]
end proc:

@nm I just edited my Reply above to clarify why I said "vast majority of cases" rather than "all cases". The only example was one posted by @Christian Wolinski years ago, and I can't remember it.

The only thing that matters for the sort key is that if x and y are two elements of indets(e,T) and x is an element of indets(y,T), then key(x) < key(y) (strict inequality).

I guess that you want to restrict the perimeter of each primary inner triangle to be integer. Do you also want to restrict each side of each triangle to be integer?

3 4 5 6 7 8 9 Last Page 5 of 704