@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);

@Markiyan Hirnyk Of course, your politeness and tact seem to be hugely appreciated.

@Markiyan Hirnyk 

See https://en.wikipedia.org/wiki/Recreational_mathematics

I really like it!

@ecterrab 

"%MeijerG() does not appear to be very inert"  because as you have used in the answer,

simplify( %MeijerG([[1/2], []], [[], []], z) );
     exp(-1/z)/sqrt(z)

I thought that this should not happen without value but it seems that `simplify/inert`  is in action here.

It would be nice to have a consistent and documented behavior.

@_Maxim_ 

About the radius of convergence R. It was computed as the limit of

u:= n -> (-2^(2+2*n)*Zeta(-n)/n!)^(-1/n);

limit(u(n), n=infinity):  simplify(%);
    Pi/2
It is true that R = Pi/2  but the above limit does not exist!

In fact,
simplify(u(2*n)) assuming n::posint;
        0

(actually this is also false,  being  0 ^ (-1/(2*n)), so, rather infinity)

The correct computation for R would involve the absolute value (abs) and liminf instead of limit
(actually  1/limsup( |a_n|^(1/n) ).
(of course liminf, limsup do not exist in Maple).

It is absolutely strange how Maple knew that we want R and cheeted to give it to us!!!