@Markiyan Hirnyk 

The following procedure, when called with nonnegint argument n, will generate the first

 (n^3 + 12*n^2 + 41*n + 48)/6

terms of the sequence.

A:= proc(n::nonnegint)
local B, R, i, j, k;
     B:= [1, 2, seq([1, seq([seq(3^i, i= 0..j), (3^(j+1)+1)/2][], j= 0..k),
          seq(3^i, i= 0..k), 3^(k+1)+1][], k= 0..n)];
     R[0]:= 5;
     for k to nops(B) do  R[k]:= R[k-1] + 2*B[k]  end do;
     convert(R, list)
end proc:

A(8);
[5, 7, 11, 13, 15, 19, 21, 29, 31, 33, 37, 39, 45, 55, 57, 63, 
  83, 85, 87, 91, 93, 99, 109, 111, 117, 135, 163, 165, 171, 189, 
 245, 247, 249, 253, 255, 261, 271, 273, 279, 297, 325, 327, 
333, 351, 405, 487, 489, 495, 513, 567, 731, 733, 735, 739, 
741, 747, 757, 759, 765, 783, 811, 813, 819, 837, 891, 973, 
975, 981, 999, 1053, 1215, 1459, 1461, 1467, 1485, 1539, 1701, 
 2189, 2191, 2193, 2197, 2199, 2205, 2215, 2217, 2223, 2241, 
2269, 2271, 2277, 2295, 2349, 2431, 2433, 2439, 2457, 2511, 
2673, 2917, 2919, 2925, 2943, 2997, 3159, 3645, 4375, 4377, 
4383, 4401, 4455, 4617, 5103, 6563, 6565, 6567, 6571, 6573, 
6579, 6589, 6591, 6597, 6615, 6643, 6645, 6651, 6669, 6723, 
6805, 6807, 6813, 6831, 6885, 7047, 7291, 7293, 7299, 7317, 
7371, 7533, 8019, 8749, 8751, 8757, 8775, 8829, 8991, 9477, 
10935, 13123, 13125, 13131, 13149, 13203, 13365, 13851, 15309, 
19685, 19687, 19689, 19693, 19695, 19701, 19711, 19713, 19719, 
19737, 19765, 19767, 19773, 19791, 19845, 19927, 19929, 19935, 
19953, 20007, 20169, 20413, 20415, 20421, 20439, 20493, 20655, 
21141, 21871, 21873, 21879, 21897, 21951, 22113, 22599, 24057, 
 26245, 26247, 26253, 26271, 26325, 26487, 26973, 28431, 32805, 
 39367, 39369, 39375, 39393, 39447, 39609, 40095, 41553, 45927, 
59051, 59053, 59055, 59059, 59061, 59067, 59077, 59079, 59085, 
59103, 59131, 59133, 59139, 59157, 59211, 59293, 59295, 59301, 
59319, 59373, 59535, 59779, 59781, 59787, 59805, 59859, 60021, 
60507, 61237, 61239, 61245, 61263, 61317, 61479, 61965, 63423, 
65611, 65613, 65619, 65637, 65691, 65853, 66339, 67797, 72171, 
78733, 78735, 78741, 78759, 78813, 78975, 79461, 80919, 85293, 
98415, 118099, 118101, 118107, 118125, 118179, 118341, 118827, 
120285, 124659, 137781, 177149]

Joe, Could you explain the significance of the operator &^ that you used? I don't mean explain mathematically, I mean explain its significance in Maple. Is there a package where differentials are expressed like that?

Joe, Could you explain the significance of the operator &^ that you used? I don't mean explain mathematically, I mean explain its significance in Maple. Is there a package where differentials are expressed like that?

@Alejandro Jakubi I decided against making a separate Question, because I now understand what's going on. By mapping simplify, I meant something a bit more elaborate:

map(simplify, J) assuming y>0, y<1;

Here's a worksheet with a simplified example of the situation. Basically, I wanted to know why generic f and Int behave differently with respect to a mapped simplify with assuming. But I understand now.

Download assuming_Int_vs_f.mw

@Alejandro Jakubi I decided against making a separate Question, because I now understand what's going on. By mapping simplify, I meant something a bit more elaborate:

map(simplify, J) assuming y>0, y<1;

Here's a worksheet with a simplified example of the situation. Basically, I wanted to know why generic f and Int behave differently with respect to a mapped simplify with assuming. But I understand now.

Download assuming_Int_vs_f.mw

@only math I think that Preben's and Axel's Answers are making the assumption z >= 0, and that that cannot be derived from the problem as stated (including the Asker's correction). I don't object; it's a natural assumption. I just want to make sure that I am reading their Answers correctly. So, I ask explicitly, are you making an additional assumption that z >= 0?

45927 + 4*17*193 = 59051

45927 + 2*3^8 = 59049

I don't know if the multiple-independent-variable case is handled at all. (Are they called partial recurrences, akin to partial differential equations?) There are no such cases in the examples at ?rsolve. Do you have reason to believe otherwise?

@Don_Caraota Also note that it is generally better to use CDF(dist,x) rather than evalf(Int(PDF(dist,t), t= -infinity..x)).

@Don_Caraota Also note that it is generally better to use CDF(dist,x) rather than evalf(Int(PDF(dist,t), t= -infinity..x)).

@acer Okay, I agree. I had tested it earlier by mapping the simplify. But it doesn't work if I map the simplify and include the assuming, even though that works for functions other than Int. I'm branching it off to a separate Question.

@acer Okay, I agree. I had tested it earlier by mapping the simplify. But it doesn't work if I map the simplify and include the assuming, even though that works for functions other than Int. I'm branching it off to a separate Question.

Do you have any idea what the simplify does in your Cartesian-coordinates integral? I noticed that if I apply simplify to the integrand (after the inner integration is done), the integrand is changed slightly, but the integral still returns unevaluated.

Do you have any idea what the simplify does in your Cartesian-coordinates integral? I noticed that if I apply simplify to the integrand (after the inner integration is done), the integrand is changed slightly, but the integral still returns unevaluated.