Carl Love

Carl Love

21905 Reputation

25 Badges

9 years, 57 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

I don't know whether you consider a typed command to be doing it "manually", or if that means via pen and paper to you. So, here's how to do it with a typed command: You say that you've "been given values of the quotient C__A0/C__AA". I will suppose that that given value is q. Then do

simplify(solve({-k*t = 1/C__A0 - 1/C__AA}, k), {C__A0/C__AA= q});
                        /      q - 1  \ 
                       { k = --------- }
                        \    C__AA t q/ 

I don't know how to do this (or much else) with menu-based commands. The presence of that side relation with q adds a level of complexity to menu-based iteractions.

You can create a custom type Monomial like this:

TypeTools:-RemoveType('Monomial'): #avoid silly warning
TypeTools:-AddType(
    'Monomial', #quotes protect against global reassignment of names
    e->
        local Var:= 'Y'[integer $ 2], Pow:= {Var, Var^rational};
        e::Pow or
        e::'specop'(
            {Pow, Not({constant, 'satisfies'(e-> hastype(e, Var))})},
            `*`
        ) 
)
:
#Usage:
type(Y[1,-3]^(-7/4)*sqrt(t+x), Monomial);
                              true

type(Y[4,3]^3*sin(Y[1,2]), Monomial);
                             false

To understand the above, you should read the help pages for the types integer, fraction, and constant, the type operator satisfies, and the commands AddType and hastype. The type `*` and the type operators { },  specop, and Not are documented (minimally) on the page ?type,structure.

The above will not work in 2D Input or in some older versions of Maple. If you're using either of those, let me know.

When entering an integral as a Maple command (rather than simply for display), do not use "d". The variable of integration is determined by the variable immediately after the comma. The pretty-printed output will still show a "d" followed by a variable.

Use this:

Exponent:= (x::algebraic)-> 
    `if`(x=0, undefined, `if`(x=1, 0, `if`(x::{`^`, specfunc(`%^`)}, op(2,x), 1)))
:

So, the result is undefined if the term is 0, it's 0 if the term is 1, it's 1 if the term is not or 1 but has no explicit exponent, and it's the explicit exponent if one appears.

Note that non-numeric denominators always become multiplicands with their exponent negated in their internal representation.

There are two problems. The first is a syntax error in one of the boundary conditions. You've entered

varepsilon + delta*D@@2*(f)

You need to change that to

varepsilon + delta*(D@@2)(f)(LB)

The second problem is that you can't use infinity as the upper boundary UB; the current numeric BVP algorithms won't allow it. I changed UB to 5. I also changed Digits to 40 because a warning message advised raising it to 32. With these changes, I got through the first set of plots. Using different parameter values, it's very likely that you'll get to some boundary-layer effects, for which you'll get the error message "Newton iteration is not converging" or "initial Newton iteration is not converging". Fixing this problem (if it happens) is a much more subtle process. 

The Sieve of Eratosthenes is great for finding large sets of small primes, but it's useless (much too slow) for finding large primes. It seems like you're interested in finding large primes, such as those found by GIMPS. Below, I have implemented the Lucas-Lehmer test for Mersenne primes, which is the same algorithm used by GIMPS.

#Compute N mod (2^n-1) via bitwise operations. N must be < 4^n.
BitMod:= (N::posint, n::posint)->
    if ilog2(N+1) < n then N
    else `if`(ilog2(N) < n, 0, thisproc(add(Bits:-Split(N, n)), n)) 
    fi
:
#Check whether (2^p-1) is prime by Lucas-Lehmer algorithm.
IsMersennePrime:= proc(p::And(prime, Not(2)))
local s:= 4;
    to p-2 do s:= BitMod(s^2, p) - 2 od;
    evalb(s=0)
end proc:
IsMersennePrime(2):= true
:
#This Mersenne prime was discovered by computer in 1979:
CodeTools:-Usage(IsMersennePrime(44497));
memory used=2.65GiB, alloc change=0 bytes, 
cpu time=10.58s, real time=12.60s, gc time=6.48s

                              true
#Verify a negative case:
nextprime(44497);
                             44501

CodeTools:-Usage(IsMersennePrime(44501));
memory used=2.64GiB, alloc change=0 bytes,
cpu time=10.34s, real time=12.54s, gc time=6.39s

                             false
#Compare timings using default method not specific to Mersenne numbers:
restart:
CodeTools:-Usage(isprime(2^44497-1));
memory used=3.73GiB, alloc change=61.50MiB, 
cpu time=59.81s, real time=63.96s, gc time=1.92s

                              true

restart:
CodeTools:-Usage(isprime(2^44501-1));
memory used=2.78MiB, alloc change=0 bytes, 
cpu time=21.45s, real time=21.47s, gc time=0ns

                             false

 

To make your example work, all that you need to do is remove the export from in front of move in module dog. In other words, this works:

animal:= module()
option object;
export 
    data1,
    move::static:= proc(_self, $)
        print("In Animal class. moving ....")
    end proc
;
end module;
 
#create class/module which extends the above
dog:= module()
option object(animal);
    move::static:= proc(_self, $)
        print("In dog class. moving ....")
    end proc  
end module;

You can verify that the method overriding and polymorphism has been done properly.

To make that work in library code, the redefinition of move should be put in a ModuleLoad procedure, like this:

dog:= module()
option object(animal);
local 
    ModuleLoad:= proc()
        move::static:= proc(_self, $)
            print("In dog class. moving ....")
        end proc;
        return
    end proc
;
    ModuleLoad()  
end module;

Like this:

PS:= PolyhedralSets:
PS:-IsInInterior(
    PS:-PolyhedralSet([[100,100]]), #point being tested
    PS:-PolyhedralSet(
        [[0,0],[200,0],[200,300],[250,400],
        [500,300],[500,500],[0,500]
    ])
);
                              true

For real and b

argument(a+b*I)

returns what you want.

This can also be done with the two-argument form of arctan:

arctan(b, a)

Given any ordering method for the remaining numbers on the board, and always combining the two largest or smallest under that ordering, the following procedure will quickly do it:

Fold:= proc(F, Ord, S::list)
local H:= heap[new](Ord, S[]);
    while heap[size](H) > 1 do 
        heap[insert](F(heap[extract](H), heap[extract](H)), H)
    od;
    heap[extract](H)
end proc
:   
F:= (x,y)-> 2*(x+y):
S:= [$1..2012]:

#Always pick the smallest 2 on the board:
CodeTools:-Usage(Fold(F, `>`, S));
memory used=9.95MiB, alloc change=0 bytes, 
cpu time=125.00ms, real time=125.00ms, gc time=0ns

                           3824690176

#Always pick the largest 2 on the board:
CodeTools:-Usage(Fold(F, `<`, S));
memory used=14.05MiB, alloc change=0 bytes, 
cpu time=157.00ms, real time=154.00ms, gc time=0ns

1418347387677553313827317733274373678617112653618997135212777674
  45156292376960567975595418039524675996632392882224586249204388
  28179304345106762174341933572125246097295862244822305888580038
  32730960812621013120919610414498768312349924004282984603838560
  56831782756113528753265460383973338290176438801802249571096171
  90072202315894651966512360194115388181951500037005049331036358
  83526253873661443899326202202911140127193485603216130264869237
  36726405401250743309372911301588481095805522276395748222142610
  57027695712811438803469660157535887649849298471803461222298792
  49120720001817791639485679807485997324175761473538

#Choose two at random:
R:= rand(0..1):
CodeTools:-Usage(Fold(F, ()-> (R()=0), S));
memory used=12.05MiB, alloc change=0 bytes, 
cpu time=188.00ms, real time=176.00ms, gc time=0ns

                         1210322911272

 

If e is your expression, do 

eval(e, Units:-Unit= 1)

Change 
for tmp in op(THE_SUMS) do
to
for tmp in THE_SUMS do

What you've shown is not a bug. If M is a module, then using the statement for x in M do implies that has a ModuleIterator or has some form of indexing implemented. Thus, the thing after the in needs to be a list, set, or other indexable structure. If THE_SUMS is a 1-element list of modules, then op(THE_SUMS) is just a module, not a sequence of modules.

The problem has nothing to do with scoping, name spaces, or whether the code is in a worksheet or library. Your attempt at making a MWE worked because you used instead of op(L).

Like this:

solve(x^(1/x)=y, x);
subsindets(%, specfunc(LambertW), L-> LambertW(k, op(L))); 
Sol:= unapply(%, [k,y]):
Sol~([-1, 0], 1.2);

                 
 [14.76745838, 1.257734541]

The two functions are simple enough that Maple can solve your problems for arbitrary coefficents (this means using convert(..., FormalPowerSeries) rather than commands series or taylor). Note that sin(x)*cos(x) = sin(2*x)/2, by standard trig identities. This means that the ratio of the coefficients of the degree-d terms will be (2^d)/2. We can get Maple to verify that directly:

f:= [sin(x)*cos(x), sin(x)];
S:= convert~(f, FormalPowerSeries);

#Taylor polynomials: Degree 9 corresponds to k=4:
value(eval(S, infinity= 4));

#Ratio of coefficients: x^d corresponds to k = (d-1)/2:
simplify(`/`(eval(op~(1, S), map2(op, [2,1], S)=~ (d-1)/2)[]));

 

The problem with using unevaluation quotes is that you still need to know the name to put in those quotes. And if you know the name, you might as well put it in string quotes in the first place. So, I don't see much practical value in unevaluation quotes for this.

On the other hand, suppose that you want to list, as strings, all the locals in the current procedure, regardless of whether they have been assigned values. In that case, you can do this:

P:= proc() 
local a:= 2, b:= 7, x;
    convert~([op](2, thisproc), string)
end proc:
P();
                        ["a", "b", "x"]

 

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