@_Maxim_ 

Of course is uses simplifications. It should  return FAIL much more frequently (when in doubt)  but it does not probably for "commercial" reasons; it prefers `false`. The assume facility deserves a much more careful implementation.

Surprisingly:
is(exp(1)+Pi,irrational);
    FAIL
So, it seems that is adopts a special strategy for properties which are not types.

Also:

is(Pi,irrational);
                              true
is(Pi^2,irrational);
                              FAIL
is(exp(1),irrational);
                              true
is(exp(1)^2,irrational);
                              FAIL
is(exp(2),irrational);
                              true

is(exp(sqrt(2)),irrational); #does not know Lindemann theorem (from 1882!)
                              FAIL

@st104290 

As you see in the example, sort itself does not alter the terms. Probably you have used some other command.
You may append assuming t>0  to that command.

@Markiyan Hirnyk 

As always you want to have the final word even when you are wrong.
But two pages earlier Fichtenholz states:  "generalized sum" (in the sense of Poisson).
He also says that actually Abel was not interested in the summation of divergent series.

Note.
In 1828 Abel wrote `Divergent series are the invention of the devil, and
it is shameful to base on them any demonstration whatsoever.'

[Abel died in 1829]

@Markiyan Hirnyk 

It is also called "power series method" or Poisson (e.g. in the Mathematical Analysis book by G.M. Fichtenholz).

@Markiyan Hirnyk 

Genericity is not strictly defined in Maple. There are plenty of such examples.
I don't think that the situation is going to change soon. The assume facility is too weak.
The correct answer for a real k should be:  piecewise(k<-1, 0, k=-1, 1, infinity)

sum(binomial(i+k,k),i=0..infinity) assuming k>-2,k<-1; #ok
                               0
sum(binomial(i+k,k),i=0..infinity) assuming k>-2,k<=-1; #wrong
                               0
sum(binomial(i-1,-1),i=0..infinity);simplify(%);
                  infinity                   
                   -----                     
                    \                        
                     )                       
                    /     binomial(i - 1, -1)
                   -----                     
                   i = 0                     
                  infinity                   
                   -----                     
                    \                        
                     )                       
                    /     binomial(i - 1, -1)
                   -----                     
                   i = 0                     
1+sum(binomial(i-1,-1),i=1..infinity);  # ok
                               1
sum(binomial(i+k,k),i=0..infinity) assuming k>=-1; # wrong
                            infinity
sum(binomial(i+k,k),i=0..infinity) assuming k>-1; # ok
                            infinity

@Preben Alsholm 

Probably the OP has converted somehow the numbers into "atomic" variables (via patettes or some 2d input "facilities").
Such as:

`#mn("13")` + 13;
     13+13

@Carl Love 

"<==" is obvious.

"==>" Follows from a lemma due to Birkhoff:

For each doubly stochastic matrix there is a permutation of the columns such that all the diagonal elements are nonzero.
(see Horn R. A., Johnson C. R. - Matrix Analysis. Cambridge 2013).

[Note that for our matrix M, (1/2)*M is doubly stochastic].

@acer 

I like Carl's main ingredient which is worth formulating explicitely:

Lemma.
A binary square matrix M has two ones in each line and each column iff
there exist a permutation matrix P and a dearangenent matrix Q such that M = (I + Q).P
(the representation is not unique).

@Carl Love 

and vote up, of course!

P.S.  Probably    runtime + time(algorithm)  >>  time(brute force)   in this case   :-)
 

@Preben Alsholm 

In other cases an error appears:

evalf(Int(1/t^2, t=I .. I*infinity));
Error, (in evalf/int) non-numeric integration limit encountered

so, probably the parameters are not correctly checked.
But anyway evalf should transform correctly the complex limits into reals.

@acer 

Just curious: is there a situation where ':-base' is really necessary instead of simply 'base'?
I cannot imagine such a possibility for name parameters.

@rlopez 

For presentations the situation is clear - use 2d input.
But for OP's specific manipulations, would you really recommend 2d input?

For the construction, a rough estimate of the chances to find the desired prime number was enough.
If you are interested in a more accurate computation, you could look for existing matematical results concerning the distribution of primes in arithmetic progressions.

BTW, I wonder why you had not objections for the rigorous primality of the number, because isprime gives only a "probabilistic" answer. You should ask for a serious proof!

This was mentioned in the post.
In our case, for  n:=10^3900,  in the interval [n-10^5, n+10^5]  should be about 22 prime numbers.

@Markiyan Hirnyk 

If you want to extract the prime number by yoursef from image do:

# v:=pasted_expression;
p:=parse(cat(entries(v,nolist))):
length(p);
isprime(p);