2 or 3 possibly new sequences from 1998

[Hans Havermann]

Since several seqfans seem to have had a look at the differences of the
"hot sequences" A097344 - A097345, but some progress had been made
during off-list discussions (credits also go to Max Alekseyev), I post
a copy of this "NEW SEQUENCE" to the list for those who might be
interested in - apologies to all others...
M.H.

%I A134652
%S A134652 59,1519,7814,17225,39079
%N A134652 Indices for which A097344 differs from A097345.
%C A134652 a(6) > 10^5.
%C A134652 These are the numbers m such that  f(m) = sum(
binomial(m,k)/(k+1)^2, k=0..m)   (binomial transform of 1/(k+1)^2),
has the same numerator than g(m) = sum( (2^(k+1)-1)/(k+1), k=0..m)
(which are also the partial sums of the binomial transformation of
1/(k+1)).
Obviously, f(m) = sum( binomial(m+1,k+1)/(k+1), k=0..m)/(m+1), and
since g(m) = (m+1) f(m)
 (cf. notes by R.Mathar on A097345), g(m) = sum( binomial(m+1,k)/k, k=1..m+1).
%C A134652 We have the equivalences:
numerator(g(n))=numerator(f(n))  <=>  (n+1) | denominator(f(n))  <=>
gcd(numerator(g(n)),n+1) = 1.
The last relation allows most efficient computation of the sequence.
%C A134652 In terms of M = m+1, the characterization reads: a(n)+1 =
numbers M such that denominator(sum(k=1,M,binomial(M-1,k-1)/k^2)) is
not a multiple of M
= numbers M such that numerator( sum( (2^k-1)/k, k=1..M)) is not co-prime to M.
%o A134652 (PARI) t=1; for( n=2,10^5, gcd(
numerator(t+=(1<<n-1)/n),n)>1 & print(n-1))
%O A134652 1
%Y A134652 A097344, A097345
%K A134652 nonn,hard,bref,more
%A A134652 Maximilian F. Hasler (Maximilian.Hasler(AT)gmail.com), Jan 25 2008




An observation about A081881: for n=2 to 17 either
floor(exp(1)*a(n-1))   (for n=2,4,16)
the values a(1) to a(17) being
1, 2, 4, 10, 26, 69, 186, 504, 1369, 3720, 10111, 27483, 74705, 203068, 
551995, 1500477, 4078718

Generalizing the bin sizes, it appears that the following is true...

If we pack bins of size x sequentially with items of size 1/k, 1/(k+1), 
1/(k+2), 1/(k+3), ...
where k = ceil(1/x), then a(n) is asymptotic to c*exp(x*n) where c is a 
constant.

For x=2, the values for a(n) are 4, 26, 188, 1385, 10230, 75586, 558505, 
... and c = .4644...
For x=3, the values for a(n) are 11, 211, 4228, 84912, ... and c = .521...

For x=1/2, the values for a(n) are
2, 3, 4, 6, 9, 14, 22, 35, 57, 93, 153, 251, 413, 680, 1120, 1846, 3043, 
5016, 8269, 13632, 22475,
37054, 61091, 100721, 166060, 273786, 451396, 744225, ... and c = .61884...

Changing the item sizes...
With bins of size 1, and with items of size 1/sqrt(1), 1/sqrt(2), 
1/sqrt(3), ...
then limit n->infinity a(n)/[a(n-1)+sqrt(a(n-1))] = 1
The values for a(n) are
1, 2, 3, 4, 6, 8, 10, 13, 16, 20, 24, 29, 34, 40, 46, 52, 59, 66, 74, 82, 
91, 100, 110, 120, 131, 142, ...
a(1000) = 247242, a(1900) = 896592

I used PARI/GP code similar to this (a bit slow) for the generalized bin 
pb=vector(100);pb[1]=0;x=.5;k=0;s=0;
for(n=ceil(1/x),900000,s=s+1./n;if(s>=x,k=k+1;pb[k]=n;s=1./n))
for(n=1,100,if(pb[n],print1(pb[n],", "),break))
for(n=1,100,if(pb[n],print(pb[n]/exp(x*n)),break))

PARI/GP code for the changed item sizes:
pb=vector(1000);pb[1]=0;x=1;k=0;s=0;
for(n=1,900000,s=s+1./sqrt(n);if(s>=x,k=k+1;pb[k]=n;s=1./sqrt(n));if(k-1000,,break))
for(n=1,30,if(pb[n],print1(pb[n],", "),break))
f(n)=pb[n]/(pb[n-1]+sqrt(pb[n-1]))
f(1000)

Regards,
Gerald

At 09:26 PM 1/25/2008, David W. Cantrell wrote:
>Rainer Rosenthal wrote:
>>David W. Cantrell wrote:
>>
>>>>>
>>>>>             a(n) = 1 + floor(C*exp(n))                 (1)
>>>>>
>>>>>    where
>>>>>
>>>>>      C = 0.1688563566671442037316797755009010341...    (2)
>>
>>>In <http://www.research.att.com/~njas/sequences/A081881>,
>>>Benoit Cloitre had already said that "a(n) is asymptotic to
>>>C*exp(n)
>>>where C=0.1688...", which I suppose that has been proven. My simple
>
>I should, rather, have said _simplistic_.
>
>>>numerical investigation seemed to indicate that
>>>
>>>               0 < a(n) - C*exp(n) < 1.                   (3)
>>>
>>>I don't know if that's always true, but if it is, then of course
>>>(1)
>>>holds for all n.
>>
>>Based on your formula for A136617 we can do more such simple
>>numerical
>>investigations in a reasonable amount of time. I did so and I found
>>that (3) doesn't hold for n = 165. I will demonstrate this now.
>
>Many thanks for your investigations! I confirm your observation.
>
>Best regards,
>David