Carl Love

Carl Love

26488 Reputation

25 Badges

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

MaplePrimes Activity


These are answers submitted by Carl Love

I'm sure that you know the standard techniques, so I wonder why they're working for me but not for you:

S:= select(type, [solve](diff(F,z), z), realcons);
allvalues(S[min[index](eval~(F, z=~ S))]);

 

@mehdibgh It should come as no surprise that fff has some negative values. So, sqrt(fff) has some imaginary values. To check, extract the min and max values from the data matrix of a plot of fff (not sqrt(fff)):

(min, max)(op([1,3], plot3d(fff, zeta__1= -1..1, eta__1= -1..1)));
              -1.68517697876451*10^(-7), 0.000874224224310557

So the negative values have relatively small magnitude, but they are there nonetheless. If fff has been constructed to be positive valued, then these negatives are from rounding errors in the huge number of floating-point calculations. In this case, just ignore the imaginary parts.

I'm amazed that anyone finds these imaginary parts surprising!

1) Plotting them all: This can be done by using plots:-display on a matrix of individual plots.

2) Finding equivalence classes (under graph isomorphism or any other property): This can be done with ListTools:-Categorize; or, if you know a function that gives an equivalence class representative, it can be done more efficiently with ListTools:-Classify.

# This likely only works in 1D-input!
#
DrawGraphs:= (L::{list,set}(Graph))->
local n:= nops(L), c:= isqrt(n);
    (plots:-display@Matrix)(
        (ceil(n/c), c), 
        (i,j)-> local k:= (i-1)*c+j; 
            if k<=n then GraphTheory:-DrawGraph(L[k], 'title'= k, _rest)
            else plot('axes'= 'none')
            fi
    ):   
n:= 50:
LG:= ['GraphTheory:-RandomGraphs:-RandomGraph(6,7)' $ n]:
ListTools:-Categorize((i,j)-> GraphTheory:-IsIsomorphic(LG[i],LG[j]), [$1..n]);
# Indices in each sublist represent isomorphic graphs.
[1, 11, 14, 15, 18, 19, 23, 24, 36, 38], [2, 41, 47, 50], [3, 5], 
  [4, 13, 44, 46], [6], [7, 12, 25, 33, 39, 49], [8], [9, 27], 
  [10, 29], [16], [17, 40], [20, 31, 34], [21, 42], 
  [22, 28, 30, 32, 48], [26], [35], [37], [43], [45]

DrawGraphs(LG);

 

To avoid the dialogs regarding the axis names, you can set environment variables like this:

_Env || (Horizont, Vertic) || alName:= (x, y):

This only needs to be done once per session (per restart), and it doesn't matter whether you do it before or after with(geometry) or whether you use with(geometry) at all. If you use geometry a lot, and you always use x and as the coordinates, then it's worth putting that command in an initialization file. On the other hand, if you often use a variety of coordinate names, then you should use Christopher's Answer.

I avoid the problem of double-quotes inside of double-quotes and the need to use backslash escaping by using back-quotes for the outermost (only!) quotes of the nprintf command:

cprint:= curry(nprintf, `#mo("%s",mathcolor="%a");`):
cprint("This is green", green);

                 This is green

cprint("This is green", red);
                 
This is green

As far as I can tell, the value of interface(typesetting) has no effect on this; however, the value of interface(prettyprint) must be 2 or 3.

Use your operating system to kill the kernel. When it's killed (which almost always happens instantly), you'll have a chance to save and close your worksheet and reopen it in another kernel. If you're using Windows, and need specific details, I can provide them.

Is there some reason that you used the undocumented and very inefficient goto rather than the a simple
proc() do print(1) od end proc():
?

It's a good thing that you suppressed the output with a colon. If you hadn't, you'd have a much bigger problem killing it. In that case, you need to kill the GUI, which kills everything, allowing you to save nothing.

Here's another way to create the transformation T and its matrix with respect to the given basis B:

restart:
Coeffs:= (e::algebraic, V::list(name))->
local t, C:= coeffs(collect(e, V, 'distributed'), V, t), T:= table(sparse, [t]=~[C]);
    t-> T[t]
:
V:= [x,y]:
T:= e-> eval(e, V=~ ([1,-1]*~(sqrt(3)*y)-~x)/2):
B:= <seq(mul(V^~[4-i, i]), i= 0..4)>:
M:= `<|>`(seq(Coeffs(T(b), V)~(B), b= B)); 

Your titular "difficulty with concatenation and indexing" is quite simply that concatenation cannot be used as a substitute for indexing by a variable (or for any other form of parameterization).

Your code can be simplified to the following; there is no need for any packages:

restart:
theta:= 2*Pi/17:
plot(
    [cos,sin]~([$0..16]*~theta), 
    style= point, symbol= solidcircle, color= red, symbolsize= 10
);

 

Wrap the command with lprint(...):

Gp:= GroupTheory:
lprint(Gp:-Generators(Gp:-SmallGroup(60,10)));

[Perm([[1, 2], [3, 8], [4, 9], [5, 10], [6, 12], [7, 11], [13, 23], [14, 24], [
15, 26], [16, 25], [17, 28], [18, 27], [19, 30], [20, 29], [21, 32], [22, 31],
[33, 44], [34, 43], [35, 46], [36, 45], [37, 48], [38, 47], [39, 50], [40, 49],
[41, 52], [42, 51], [53, 58], [54, 57], [55, 60], [56, 59]]), Perm([[1, 3], [2,
8], [4, 13], [5, 14], [6, 15], [7, 16], [9, 23], [10, 24], [11, 25], [12, 26],
[17, 33], [18, 34], [19, 35], [20, 36], [21, 37], [22, 38], [27, 43], [28, 44],
[29, 45], [30, 46], [31, 47], [32, 48], [39, 53], [40, 54], [41, 55], [42, 56],
[49, 57], [50, 58], [51, 59], [52, 60]]), Perm([[1, 4, 5], [2, 9, 10], [3, 13,
14], [6, 17, 19], [7, 18, 20], [8, 23, 24], [11, 27, 29], [12, 28, 30], [15, 33
, 35], [16, 34, 36], [21, 39, 41], [22, 40, 42], [25, 43, 45], [26, 44, 46], [
31, 49, 51], [32, 50, 52], [37, 53, 55], [38, 54, 56], [47, 57, 59], [48, 58, 
60]]), Perm([[1, 6, 21, 22, 7], [2, 11, 31, 32, 12], [3, 15, 37, 38, 16], [4, 
17, 39, 40, 18], [5, 19, 41, 42, 20], [8, 25, 47, 48, 26], [9, 27, 49, 50, 28],
[10, 29, 51, 52, 30], [13, 33, 53, 54, 34], [14, 35, 55, 56, 36], [23, 43, 57,
58, 44], [24, 45, 59, 60, 46]])]

I used copy-and-paste to transfer that output to MaplePrimes. Yes, it's slightly different from the original display, but perhaps acceptable to you.
 

You've entered your proposed solution as 

1/root(cos(x)^2 * 8*cos(x)-3 * sin(x),3)

You're missing parentheses in that. The actual solution is

1/root(cos(x)^2*(8*cos(x) - 3*sin(x)), 3)

This can be shown to be equivalent to dsolve's solution. That's not difficult to do, but not trivial either.

It is a long-standing design flaw of Maple that symbolic constants (such as Pi) are are often superficially treated as if they were variables until you give some high-level command (such as simplify) that has detailed knowledge about them. In the following example (which is, of course, highly contrived just to illustrate my point) the high-level command is is:

if Pi > -1 then infinity else -infinity fi;
Error, cannot determine if this expression is true or false: -1 < Pi
if is(Pi > -1) then infinity else -infinity fi;
                           
infinity

But this example works without needing any special prompting:

limit((Pi-4)*x, x= infinity);
                           - infinity

It's easy to replace the labels directly in the plot structure, which gets around the problem of duplicate labels.

restart:
Gp:= GroupTheory:
S4:= Gp:-SymmetricGroup(4):
L:= Gp:-GroupOrder~(Gp:-SubgroupLattice(S4, output= list)):
subs(cat~("", [$1..nops(L)])=~ cat~("",L), Gp:-DrawSubgroupLattice(S4));

Those are two completely different usages, which only coincidentally look similar, and neither is specifying a value of f. The command with the f, 3 is

map(series, M1, f, 3)

where M1 is actually some command that returns a matrix. The 3 is passed on to series as its third argument, which specifies the "order" of the series. Let me know if you need to know what "order" means in this context, or see the help page ?series. This 3 is indeed "arbitrary" and optional: It could be omitted or replaced by any larger integer. If omitted, the global environment variable Order is used; its default value is 6. (Order is similar to Digits, which I mention because it's a global environment variable that nearly all users are familiar with.)

The command with the f, 0 is

map(coeff, M2, f, 0) 

where M2 is also a matrix---the result of the command from the previous paragraph. The 0 is passed on to coeff as its third argument, which specifes the degree (i.e., the exponent of f) for which the coefficient is wanted. So, means the terms that don't have f. Your senior is wrong about this one being "arbitrary": Changing or omitting the 0 will lead to different results; they'll be the coefficients of some higher power of f.

Throughout all of this, is a purely symbolic independent variable. So, it doesn't have any "values", contrary to what you thought as indicated by your first sentence. Despite its name, it does not represent a function. Perhaps it'll become a function in some later usage of this code, which may justify the author's choice of the slightly confusing name f

Let me know if you need more details on any of that.

I've noticed that many of your Questions involve using solve in a for loop to solve for a variable that is absolutely trivial to solve for by hand. The following produces exactly the same results as Tom Leslie's version of your code, but it doesn't use solve:
 

restart;

delta:= table(sparse):
F:= table([0=0, 1=0, 2=A]):   

for k from 0 to 10 do
    F[k+3]:= expand(
        (
            add(
                (sin(beta)*F[k-m] - cos(beta)*delta[k-m-1])
                * (m+1)*(m+2)*F[m+2],
                m= 0..k
            )/2
            - M(k+1)*F[k+1]
        )/`*`(k+~(1,2,3))
    )
od;
       

0

-(1/24)*M(2)*A

(1/60)*sin(beta)*A^2

(1/2880)*M(4)*M(2)*A

-(1/720)*sin(beta)*M(2)*A^2-(1/12600)*M(5)*sin(beta)*A^2

(11/20160)*sin(beta)^2*A^3-(1/967680)*M(6)*M(4)*M(2)*A

(1/90720)*sin(beta)*M(4)*M(2)*A^2+(1/48384)*sin(beta)*M(2)^2*A^2+(1/362880)*M(7)*sin(beta)*M(2)*A^2+(1/6350400)*M(7)*M(5)*sin(beta)*A^2

-(1/17280)*sin(beta)^2*A^3*M(2)-(11/4536000)*sin(beta)^2*A^3*M(5)-(11/14515200)*M(8)*sin(beta)^2*A^3+(1/696729600)*M(8)*M(6)*M(4)*M(2)*A

(5/266112)*sin(beta)^3*A^4-(29/958003200)*sin(beta)*A^2*M(6)*M(4)*M(2)-(7/22809600)*sin(beta)*M(4)*M(2)^2*A^2-(1/89812800)*M(9)*sin(beta)*M(4)*M(2)*A^2-(1/47900160)*M(9)*sin(beta)*M(2)^2*A^2-(1/359251200)*M(9)*M(7)*sin(beta)*M(2)*A^2-(1/6286896000)*M(9)*M(7)*M(5)*sin(beta)*A^2

(401/958003200)*sin(beta)^2*M(4)*M(2)*A^3+(563/319334400)*sin(beta)^2*A^3*M(2)^2+(37/479001600)*sin(beta)^2*A^3*M(7)*M(2)+(37/8382528000)*sin(beta)^2*A^3*M(7)*M(5)+(1/14784000)*sin(beta)^2*M(2)*A^3*M(5)+(1/22809600)*M(10)*sin(beta)^2*A^3*M(2)+(1/544320000)*M(10)*sin(beta)^2*A^3*M(5)+(1/1741824000)*M(10)*M(8)*sin(beta)^2*A^3-(1/919683072000)*M(10)*M(8)*M(6)*M(4)*M(2)*A

-(5023/2075673600)*sin(beta)^3*A^4*M(2)-(173/1945944000)*sin(beta)^3*A^4*M(5)-(23/1132185600)*sin(beta)^3*A^4*M(8)+(23/597793996800)*sin(beta)*A^2*M(8)*M(6)*M(4)*M(2)+(17/19926466560)*sin(beta)*M(2)^2*A^2*M(6)*M(4)+(1/948879360)*sin(beta)*M(4)^2*M(2)^2*A^2-(5/456648192)*M(11)*sin(beta)^3*A^4+(29/1643933491200)*M(11)*sin(beta)*A^2*M(6)*M(4)*M(2)+(7/39141273600)*M(11)*sin(beta)*M(4)*M(2)^2*A^2+(1/154118764800)*M(11)*M(9)*sin(beta)*M(4)*M(2)*A^2+(1/82196674560)*M(11)*M(9)*sin(beta)*M(2)^2*A^2+(1/616475059200)*M(11)*M(9)*M(7)*sin(beta)*M(2)*A^2+(1/10788313536000)*M(11)*M(9)*M(7)*M(5)*sin(beta)*A^2

 

Download NoSolve_(1).mw

Your procedure can be made faster by

  1. using diff instead of D,
  2. simplifying binomial(n,k)/n! to 1/((n-k)!*k!),
  3. remembering and re-using the derivatives and factorials of smaller orders.
restart:
Taylor2V:= proc(f::algebraic, V::[name= algebraic, name= algebraic], N::posint:= Order)
local 
    v:= lhs~(V), V0:= (lhs-rhs)~(V)[], n, k, 
    `!`:= proc(n) option remember; n*thisproc(n-1) end proc,
    D:= proc(n,k)
    option remember;
        `if`(k=0, diff(thisproc(n-1, 0), v[1]), diff(thisproc(n, k-1), v[2]))
    end proc
;
    D(0,0):= f; `!`(0):= 1; #Initialize remember tables.
    add(add(eval(D(n-k,k), V)*`*`(V0^~(n-k, k))/`!`(n-k)/`!`(k), k= 0..n), n= 0..N)
end proc
:
f:= 1/(2+x*y^2):
S:= CodeTools:-Usage(Taylor2V(f, [x=0, y=0], 30)):
memory used=5.49MiB, alloc change=32.00MiB, 
cpu time=31.00ms, real time=32.00ms, gc time=15.62ms

This Answer is intended for your general education into how to make Maple procedures faster. But you'll never make this as fast as mtaylor because mtaylor (which is written in Maple) calls series (which is NOT written in Maple) using VV's trick.

First 34 35 36 37 38 39 40 Last Page 36 of 382