to all OEIS contributors

[deutsch]

should be more careful with the submission of new sequences.
submitted to journals are 
sequences, we ourselves have to do the refereeing and the
Return-Path: <pauldhanna at juno.com>
X-Ids: 164
X-UNTD-OriginStamp: oDbjeIy1VJ6V0JV5e6a+hzbyM+D6FMBNHLWuvnotEXHgOUM136qlVQ==
To: Seqfan at ext.jussieu.fr
Date: Tue, 13 Nov 2007 01:07:38 -0500
Subject: Re: Sequences A120588 - A120607 : Formulas?
Message-ID: <20071113.010739.168.1.pauldhanna at juno.com>
X-Mailer: Juno 5.0.33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-18,20-38
From: "Paul D. Hanna" <pauldhanna at juno.com>
X-ContentStamp: 13:6:2914956799
X-MAIL-INFO: 0dbef713bef7dfdaf797abdeabdb3a47a702873e339bcf834b8abeefcf839fe3bbf35a13be1713cf7e1a33ab2a13aada8a5e4a8ada4a4a5b3adb736a9ac30acbc7f3f3
X-UNTD-Peer-Info: 127.0.0.1|localhost|outbound-jn.dca.untd.com|pauldhanna at juno.com
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Tue, 13 Nov 2007 07:12:27 +0100 (CET)
X-Virus-Scanned: ClamAV 0.88.7/4757/Mon Nov 12 18:20:27 2007 on shiva.jussieu.fr
X-Virus-Status: Clean
X-j-chkmail-Score: MSGID : 47394049.002 on shiva.jussieu.fr : j-chkmail score : X : 0/50 1 0.303 -> 1
X-Miltered: at shiva.jussieu.fr with ID 47394049.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!

Seqfans, 
     Given the functional equation: 
(1)   r*A(x) = c + b*x + A(x)^n 
the series solution: 
(2) A(x) = Sum_{i>=0} C(n*i,i)/(n*i-i+1)*(c+bx)^(n*i-i+1)/r ^(n*i+1) 
can also be expressed as:
 
(3) A(x) =  G( (c+bx)^(n-1)/r^n ) * (c+bx)/r 
 
where G(x) satisfies:  G(x) = 1 + x*G(x)^n .
 
So Ralf and Emeric were correct after all - 
there really is not much difference in their g.f.s and (1). 
 
Yet I am still interested in an explicit formula for a(n) ... 
is it a simple matter now of summing over binomials? 
Thanks, 
      Paul 
 
On Tue, 13 Nov 2007 00:33:40 -0500 Paul D. Hanna <pauldhanna at juno.com>
writes:
> Seqfans,
>       Thanks, Ralf and Emeric, for your interesting thoughts ; 
> however, there is a difference between your g.f.s 
> and the g.f.s that I am interested in here.
>  
> The point of interest (to me) in the g.f. A(x) that satisfies: 
> (1)   r*A(x) = c + b*x + A(x)^n 
[...]
>  
> SERIES SOLUTION. 
> Well, the following is not explicit, but one can apply the 
> Lagrange Inversion Theorem 
> http://mathworld.wolfram.com/LagrangeInversionTheorem.html
> to obtain an infinite series solution to (1): 
>   
> (2) A(x) = Sum_{i>=0} C(n*i,i)/(n*i-i+1)*(c+bx)^(n*i-i+1)/r ^(n*i+1) 
>  
> given c, b, and r are sufficient to allow convergence. 
[...]



This is an area I'm starting to explore; do you think sequences based on
algorithms/functions are acceptable for inclusion in the OEIS? For instance,
here's a sequenced based on PARI's "nextprime" and "sqrtint" functions:


9, 25, 35, 49, 55, 65, 77, 85, 91, 119


These are "balanced" composites with exactly two prime factors. The PARI
equation I used to find them is:


bal(x,y) = nextprime(sqrtint(x)+y) * nextprime(sqrtint(x)-y)


The process is relatively straightforward; x is a composite number with two
prime factors. Plug in values for y from 0 up to the integer square root of
x. If the output is the same as x, then the number is "balanced". For
example:


bal(25,0) = nextprime(5 + 0) * nextprime(5 - 0) = 5 * 5 = 25

bal(35,1) = nextprime(5 + 1) * nextprime(5 - 1) = 7 * 5 = 35

bal(119,4) = nextprime(10 - 4) * nextprime(10 + 4) = 7 * 17 = 119

etc.


However, I'm not sure if the "nextprime" function in PARI is the same as,
PARI, for instance, "nextprime" will check if the starting value itself is
prime and, if it is, will return that value. Other implementations may not
check the starting value to see if it's prime, in which case squares of
primes would be excluded from this sequence. The same issue exists for the
"sqrtint" function; I believe PARI always rounds down, while the rounding

The sequence is of interest to me and well-defined, but I hesitate to submit
it (after finding more terms) because of potential differences between
implementations of the "nextprime" function and the "sqrtint" function.