x->x*ceiling(x)

[Richard Guy]

Some years ago I had some corresp c David about
 this, and we tried `ceiling', `floor'. `nearest
integer', and combinations thereof, such as
UDUDUD....  and UUDUUDUUD...  My recollection
is that results were similar.  R.

On Fri, 30 Aug 2002, Roland Bacher wrote:

> > On Thu, 29 Aug 2002, David Boyd wrote:
> > 
> > > In answer to John's question, the result about 14,23 is in
> > > my paper in Acta Arith, v. 24 (1977), 89--98.   Shortly
> > > thereafter, I was able to show that starting with any of
> > > the following gives a Pisot sequence which is not linearly
> > > recurrent:  7,15   8,14   9,15  9,17  9,19  10,18  10,21.
> > > David Cantor suggested that probably 4,13  also is a bad
> > > starting pair.   One of my old Macs did a computation
> > > verifying this but since it ran for a few months I wouldn't
> > > claim that this has yet been proved, but if true it is
> > > a matter of a finite computation.
> > 
> >    Could you briefly explain how you prove such things
> > (and in particular, why they reduce to finite computations)?
> > 
> > > I don't think the sequences generated by  x -> x*ceil(x)
> > > have much to do with Pisot sequences....
> > 
> >    I didn't think there was much real resemblance either -
> > just a reminiscence, so to speak.  
> > 
> >    Regards, John Conway
> > 
> 
> I cannot prove that the sequence gotten by iterating 
> x->x*ceil(x) and starting with x_0=1+1/n   gets always integral,
> but it does so for n=1,....,100.
> 
> the first integral indices are:
> 
> 0, 1, 2, 3, 18, 2, 3, 4, 6, 7, 26, 4, 9, 3, 4, 8, 6, 4, 56, 11, 3, 4, 42, 4, 33, 7, 5, 4, 38, 5, 79, 6, 4, 15, 14, 8, 200, 29, 13, 5, 36, 3, 4, 5, 7, 10, 11, 8, 6, 20, 47, 27, 43, 9, 41, 9, 10, 23, 37, 17, 18, 6, 7, 6, 32, 15, 225, 7, 73, 11, 20, 12, 182, 9, 16, 7, 10, 15, 196, 8, 11, 62, 23, 5, 26, 4, 5, 8, 85, 11, 18, 61, 22, 177, 59, 10, 187, 10, 20, 6
> 
> local maxima are achieved for n=1,2,3,4,5 (18), 11 (26), 19 (56), 37 (200) and
> 67 (225)  .
> 
> hence x_{18} \in N for x_0=1+1/5;
> 
> I have computed these values by doing all computations over the integers
> (multiply by n) and by truncating modulo n^250. This avoids the explosion
> of the integers (of order 2^(2^k) after $k$ iterations) 
> and gives the correct answer if the final index i(n) is < 250 
> (or perhaps 249 or 248). If the algorithm does not stop befor 245 you should
> increase precision (work with n^500 or even higher).
> 
> Roland Bacher
>