Surely either you have transcribed the problem incorrectly or your copy has a typo. Let f(k) = 2*k/(2*k+3), and consider the limit

L:= limit(n^p*sum(f(k), k= 1..n), n= infinity)

for a fixed real parameter p. It is easy to prove (and I'll prove it if you want) that L = 0 if p < -1, L = 1 if p = -1, and L = infinity if p > -1. One doesn't even need to know a closed form for the sum to prove this.

@_Maxim_ Yes, I see that 'type' now; I missed it last night. I was thrown off by the And(complexcons, Not(infinity)). That's already a valid type, so why does it get special mention? Perhaps infinity wasn't a type when the code was written.

The age of the code is also shown by map(type, {op(e)}, 'property') = {true} . In modern Maple, this could (and should) be replaced by andmap(type, e, 'property').

I didn't disagree with Acer about a type being usable anywhere that a property was. I merely said that if it isn't also specifically coded as a property (e.g., by being listed in `property/ParentTable`), then there was nothing interesting that is could do with it. I mean, yes, you can use is as a replacement for a dedicated type checker, but I don't think that it's wise to do so.

@vv It was mostly wishful thinking on my part. Upon delving into the code, I think that is is a huge mess, and that a lot of what I wrote above is wrong. Since is is fundamental to Maple, and the person who wrote it (Gaston Gonnet, I believe) is not maintaining/updating it, perhaps Maplesoft is afraid to touch it for fear of breaking something.

Regarding "Of course, any type is a property": Read the very simple procedure `type/property`. That'll tell you exactly which types are properties. It'll also help you distinguish the proper properties: those that have a definition other than as types.

@Ramakrishnan You need to enclose the SetProperty commands inside of print commands, like this: print(SetProperty(  whatever ));

It makes no difference whether you end the commands inside the loop with colons or semicolons.

Are you going to post your algorithm?

@tomleslie CodeTools:-Usage is just a Maple-level wrapper for calling the kernel command time(); there's no finer-resolution tool available. You can see this in the code

kernelopts(opaquemodules= false):
showstat(CodeTools:-Usage);
showstat(CodeTools:-DoUsage);

In particular, pay attention to lines 5-10 of DoUsage.

The following explicitly measures the time quantum:

restart:
Quantum:= proc()
local n, T:= 0;
   for n while T=0 do
      T:= CodeTools:-Usage(0, output= cputime, quiet)
   end do;
   [n, T]
end proc:
    
Interval:= proc()
   Quantum();
   Quantum()
end proc:

gc(): gc(): gc(): gc():
CodeTools:-Usage(Quantum());
CodeTools:-Usage(Interval());

memory used=35.14MiB, alloc change=0 bytes, cpu time=250.00ms, real time=247.00ms, gc time=15.62ms
                         [11335, 0.015]
memory used=44.19MiB, alloc change=0 bytes, cpu time=282.00ms, real time=285.00ms, gc time=15.62ms
                         [8498, 0.016]

This shows that CodeTools:-Usage will report 0 seconds thousands of times for the cpu time of a trivial expression, and then report either 15 or 16 milliseconds for a single execution of the same trivial computation. The number of times (11335 and 8498 in this case) will vary, but the second number will always be 0.015 or 0.016.

Please show an example where CodeTools:-Usage shows a smaller nonzero cpu time. Examples using the iterations option, which averages the time over a large number of iterations, don't count.

@Kitonum Here's the code modified to produce all 6x6 binary matrices with three 1s in every row and column. It produces 297200 such matrices in listlist form in 33 seconds.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id:= [seq([seq(`if`(i=j, 1, 0), j= 1..n)], i= 1..n)]:
D1:= remove(p-> ormap(evalb, p =~ N), Sn):
MA:= {seq(
   seq(M[p], p= Sn), 
   M= seq(
      seq(
         Id+Id[d1]+Id[d2], 
         d2= remove(p-> ormap(evalb, p =~ d1), D1)
      ), 
      d1= D1
   )
)}:
time() - st;

@Kitonum To get 3 ones per row and column, make the initial set all matrices of the form I + I[d1] + I[d2] where d1 is a derangement of [1..6] and d2 is a derangement of both [1..6] and d1.

@vv Thank you for formulating the theorem. I was not confident of its truth until I ran the code. Still, it needs proof.

Regarding the algorithm development time: I read Kitonum's initial posing of the problem right before I went to bed. I came up with the algorithm as I fell asleep, about 5 - 10 minutes.

@acer I had already been considering the changes that you suggested. Indeed they produce the same results. I have often commented here on MaplePrimes about how incredibly slow the constructor Matrix is.

By making a few more changes, I've got the time under 0.9 seconds. And if one is content with listlist form for the final results, I can do it in under 0.3 seconds.

restart:
gc():
st:= time():
n:= 6:
N:= [$1..n]:
Sn:= combinat:-permute(n):
Id:= [seq([seq(`if`(i=j, 1, 0), j= 1..n)], i= 1..n)]:
I0:= subs([0=1, 1=0], Id):
MA:= {seq(
         seq(M[p], p= Sn), 
         M= seq(I0-Id[d], d= remove(p-> ormap(evalb, p =~ N), Sn))
     )}:
time() - st;
MA:= {seq(rtable(M, subtype= Matrix), M= MA)}:
gc():
time() - st;

@_Maxim_ I can't conceive of any use for the ranges of properties. If assume(x::(a..b)) did mean that x has property b but not property a, that could conceivably be useful; but it doesn't mean that, as shown by

is(2, rational..real);

     true

It seems that assume(x::(a..b)) is the same as assume(x::b).

You asked for a list of the known properties. I think that everything that is initially known about properties is contained in the following tables:

eval(`property/ParentTable`);
eval(`property/ChildTable`);
eval(`property/ExclusiveTable`);

It's not much of a knowledge base.

As far as I'm aware, Maple's property system hasn't been updated (*footnote) during the entire time that I've been using Maple, which is since 1999. The assuming operator was added early in my Maple time, but it's just a wrapper that calls assume with no change to the underlying properties, as you can verify by showstat(`assuming`).

*footnote: There is apparently a separate assume/property facility that can be used by the Physics package. This package seems to be vigorously maintained and updated.

@dpaddy We can't really follow along unless you post your code in a reproducible format, but to my naked eye, it appears that your expression is simply a rational function of x with constant coefficients. I have a hard time believing that Maple can't accurately compute its residue.

@Rouben Rostamian  It looks like the OP is already using abs.

The OP should post the function in a reproducible format so that we can work with it.

@_Maxim_ Correct, as far as type is concerned RealRange(0,2) might as well be foo(0,2)---it's just a function.

You should also read ?in, which describes an operator SetOf whose argument is a type; however, I've never encountered a situation where a computation using SetOf couldn't be expressed more succinctly without it.

@acer The McCarthy short-circuit evaluation rules for boolean operators apply to the infix forms of and, or, and implies but not to their prefix forms. Thus, with the infix forms, if the truth of the whole expression can be determined from the left operand, then the right operand isn't even evaluated; whereas with the prefix forms, all arguments are evaluated regardless. This explains some of Maxim's anomalies.

I don't think that it applies to this Question, but a further source of anomalies is that in 2D Input (at least in some versions) the infix boolean operators are translated to their prefix forms.