Carl Love

Carl Love

24663 Reputation

25 Badges

10 years, 56 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity

These are answers submitted by Carl Love

You can combine an Interpolation object with a regular function in a numeric integrand as in this example:

P:= plot(sin(x), x= 0..Pi):
XY:= op([1,1], P):
f:= Interpolation:-SplineInterpolation(XY):
int(x-> f(x)/(1+x), 0..Pi, numeric);

If such an integral returns unevaluated, reduce the precision with the epsilon option:

int(x-> f(x)/(1+x), 0..Pi, epsilon= 5e-7, numeric);

There are a few other problems in your code, unrelated to the issue corrected by acer. The most prominent of these problems is this: Once a procedure executes a return statement, it stops executing. Thus, in places where you have two or more return statements in succession, only the first can possibly be executed. You can get around this by returning multiple values in a single return statement, for example 

return p, q, r

Here are corrections to your procedure:

conjcl:= proc(k::integer, p::prime, n::posint)
local q:= p^n-1, L:= Array(1..0), K:= 0, t;
    for t do K:= K+k mod q; L(t):= K; if K=0 then break fi od;
end proc


                     [3, 6, 2, 5, 1, 4, 0]

Note that for your example values q = p^n - 1 = 7 is itself prime. That's a very rare occurence; there are only 51 known pairs (p,n) for which it happens. It's easy to prove that it can only happen for p = 2 and prime. The upshot is that the returned list has all the integers 0..6 for any not a multiple of 7, and thus the conjugacy class is the entire multiplicative group of the field. In general, that will only happen when k and q are relatively prime, i.e., when their greatest common divisor (GCD) is 1.

Here are the errors with your original procedure:

  1. t needs to start at 1, not 0.
  2. It's the multiples of k, not the powers of p, that matter; indeed p could never be a generator (a.k.a. primitive element) of the field GF(p^n).
  3. Maple's mod doesn't distribute over <>.

This procedure is much simpler using syntax that is only available in 1D input:

conjcl:= (k::integer, p::prime, n::posint)->
local q:= p^n-1, K;
    [for K from k by k do K mod= q until K=0]

The need for an index variable in add and related looping statements can very often be avoided by using elementwise operations. I've typed the below in 1D, but they work in 2D also:

Omega:= (a::list)-> (-1)^add(a -~ 1);
Omega__rev:= (a::list)-> (-1)^add(a -~ [$nops(a)]);

There are many possible variations of the above, many of which avoid the internal creation of a temporary list. Here are two such possibilities for each:

Omega:= (a::list)-> (-1)^(add - nops)(a);
Omega:= curry(`^`, -1)@(add - nops);

Omega__rev:= (a::list)-> (-1)^(add - (n-> n*(n+1)/2)@nops)(a):
Omega__rev:= curry(`^`, -1)@(add - (n-> n*(n+1)/2)@nops):

I use curry and rcurry so often that I have the following predefined:

`&<`:= curry:  `&>`:= rcurry:

Using those, the above can be:

Omega:= `^`&<(-1) @ (add - nops):
Omega__rev:= `^`&<(-1) @ (add - binomial&>2 @ (nops+1)):


I think that you're misinterpreting the prettyprinted output of a permutation group object as a string. If you apply lprint to the output, you'll see that it's actually the PermutationGroup constructor. However, if you truly have a string such as you say, it can be converted to the group with this procedure:

StringToGroup:= proc(S::string)
uses ST= StringTools, GT= GroupTheory;
                parse(ST:-SubstituteAll(ST:-SubstituteAll(S, ")(", ")*("), "(", "_("))
            `*`, op
        _= `[]`
end proc
StringToGroup("<(1, 2), (1, 2, 3)(4, 5)>");
                <(1, 2), (1, 2, 3)(4, 5)>        

GroupTheory:-PermutationGroup({Perm([[1, 2]]), Perm([[1, 2, 3], [4, 5]])},
degree = 5)


It should be 

cutoff:= eval(t, tempLrest[2])

The reason is that classical methods (almost by definition of classical) don't have dynamic error control such as variable step length. So, they are ignoring the errors that rkf45 is trying to prevent.

I don't know much about these ODEs with random input (are they stochastic DEs such as used in finance?), but perhaps ignoring the error controls is in fact useful.

There is a bug that occurs when a procedure containing `<|>`( saved as plaintext: It's actually saved as `<,>`(...). This doesn't happen if it's saved in internal format rather than plaintext. Here's a worksheet that proves and documents the existence of this bug and shows how to work around it.


Row:= ()-> `<|>`(args);

proc () options operator, arrow; `<|>`(args) end proc

# Despite the erroneous way that Row is prettyprinted above, it works correctly...

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

# ...and closer inspection via ToInert(eval(Row)) will show that the internal
# procedure is indeed `<|>`, not `<,>`.
# However, when the procedure is saved **as plaintext**...
save Row, "/Users/carlj/desktop/Row.mpl";

#'s saved as if it were actually that erroneously printed form:

"Row := () -> <_passed>;

# Thus, it doesn't work correctly when read back in from the plaintext:
read "/Users/carlj/desktop/Row.mpl":

Vector(2, {(1) = 1, (2) = 2})

# This shows a way to work around the bug:
Row:= ()-> `<|>`(args):
# Save in internal ".m" format:
save Row, "/Users/carlj/desktop/Row.m":


M:= module() option package;
export Row;
    # $include won't work for ".m" file. You need to do this instead:
    read "/Users/carlj/desktop/Row.m"; Row:= eval(:-Row)
end module:

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

# And that'll still work when the module is saved to a ".mla".



I consider this a "very bad" bug. But I suspect that it'll be very easy for Maplesoft to fix it.

My workaround is very kludgy and quick-and-dirty. It's only intended as a stop-gap workaround, not as a "fix".

It can be easily proven to converge by doing a Direct Comparison Test with Sum(1/n^4, n= 1..infinity).

Since Maple doesn't "know" that n < ithprime(n) for all positive integers n

is(n < ithprime(n)) assuming n::posint;

we can't get Maple to do that Direct Comparison Test. Nonetheless, that inequality is obvious, as is the complete application of the Test to this problem.

This is something called "last name evaluation" that only applies to tables, procedures, and modules. (See help page ?last_name_eval.) The expression atable["b"] hasn't been fully evaluated. If you change the last line to whattype(eval(atable["b"])), it'll respond table. (I'm not recommending that you use eval there in general; this is just for explanatory purposes.) For atable["a"], the "last name" in the evaluation chain is a; for atable["b"], it's atable["b"] (an indexed name). What I recommend that you do in practice is change the 3rd command to atable["a"]:= eval(a); then the later eval is not needed.

You didn't say what your Maple version was. If you have a fairly new version of Maple, then your first question can be solved like this:

In:= (a, S::set(set))-> select[2](member, a, S):

For older Maple, change that to this:

In:= (a, S::set(set))-> select(curry(member, a), S):


X:= {a,b,c,d}:

             {{a, b}, {a, b, c}}

For your second question, use

XxX:= (S::set(set), X::set)-> 
    (a-> `[]`~(a, `intersect`(In(a,S)[]))[])~(X intersect `union`(S[]))

             {[a, a], [a, b], [b, b], [c, c]}

To exclude the diagonal elements, change to

XxX:= (S::set(set), X::set)-> 
    (a-> `[]`~(a, `intersect`(In(a,S)[]) minus {a})[])~(X intersect `union`(S[]))

{[a, b]}

It is a widespread myth that Maple's for-loops are slow.


The message means that items that should have been numeric plot coordinates were actually unassigned variables, presumably because those global variables mentioned in the procedure were not given values before the procedure was called.

I don't know if you want them to be on the same row. If not, you could do

for g in lis[10..20] do 
    print(DrawSubgroupLattice(SmallGroup(g), 'highlight' = CompositionSeries(SmallGroup(g))))

Or, you could limit the number of groups per row to, say, 4, with each as large as possible so that 4 would fit.

The right side of ode1 should be square_wave_periodic(t).

I'm always skeptical of assuming some_property without specifying variables. If you change it to assuming x::real, then it works. Otherwise, some problem occurs when it tries to also assume that right is real. I don't know why that only happens when you use quotes.

I assume that you know that the assumption real is redundant when using left or right, but for whatever reason you want to use it anyway.

Another solution is to make right protected. (I guess that assumptions on unspecified variables don't apply to protected variables.)

protect(right); of your code...

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