[seqfan] Re: tan(n). Was: Into subtleties of musical information

[Antti Karttunen]

On Tue, May 26, 2015 at 7:11 PM, Antti Karttunen
<antti.karttunen at gmail.com> wrote:
> On Tue, May 26, 2015 at 6:02 PM, Veikko Pohjola <veikko at nordem.fi> wrote:
>> I do not see what relevance has the property tan(n) > n here. Let us take n=118554299812338354516058. Floor(tan(n)=1.
>
> The relevance is quite direct as I was searching for cases of any n >
> 1 where floor(tan(n)) is somewhat near to n, and also wondering
> whether it can ever be larger than n, as to estimate the possibility
> of any other positive fixed points than 1 for floor(tan(n)).
>
>
> Theoretically there might be also fixed points less than zero. And
> even more theoretically, there might even exist a sequence of
> iterations starting from some n which would never seem to set to a
> fixed point, although I guess it would be even unlikelier than the
> existence of these hypothetical fixed points < 0 or > 1.
>
> But, like I said in PinkBox-comment 09:46 of https://oeis.org/draft/A258024
>
> I would prefer more inclusive definition(s) for this/these sequence(s)
> (this and A258022), because then it/they would offer a home for any
> hypothetical orphan rarity (a fixed point < 0 or > 1), if such are
> ever found, but not enough (3 terms) is found to create a wholly new
> sequence.
>
> (i.e. for numbers which when iterated with x -> floor(tan(x)) would
> set to such a rare fixed point r, with at least r being one of them).
>
> Please remember that the existence of all these extra fixed points is
> just a remote possibility, and if your conjecture about their
> nonexistence holds, then it will not affect the contents of any of
> these sequences, but would just safeguard their elegance in case such
> a monster is ever found.

Checking with the sixteen terms computed for
https://oeis.org/A249836 "Numbers for which tan(n) > n. "

(define A249836lista '(1 260515 37362253 122925461 534483448 3083975227
 902209779836 74357078147863 214112296674652
 642336890023956 18190586279576483
 248319196091979065 1108341089274117551
 118554299812338354516058
 1428599129020608582548671
 4285797387061825747646013))


(length A249836lista)
;Value: 16

I find that ...
(map A000503 (list-head A249836lista 13))
;Value 64: (1 383610 37754921 326917636 1917073027 14105010812
-861333938 -10446223 -3627772 -1209258 -1 -2 -8)

and the fourteenth term 118554299812338354516058 is already too much
for MIT/GNU Scheme:
(map A000503 (list-head A249836lista 14))
;The object #[NaN], passed as the first argument to
flonum-floor->exact, is not the correct type.

But for the first thirteen, all eventually reach either 0 or 1 when iterating:
(map A258021 (list-head A249836lista 13))
;Value 66: (1 0 0 0 0 0 0 0 1 0 0 0 0)

And Veikko said in http://list.seqfan.eu/pipermail/seqfan/2015-May/014914.html

"It is these iterated values we are hunting here and this one reduces
to 1 right away at the first level."

and my concern has been all the time that there just _might_ be some
extra fixed points lurking for function floor(tan(n)) there, in which
case for any such fixed point r = floor(tan(r)), at least the number r
(fixed point) itself reduces to something else than 0 or 1 (Even if it
is not an image of any other number) and would be thus outside of
A258022 and A258024 as currently defined.

But it seems that at least up to 1108341089274117551 = A249836(13)
there is none at the positive side. I assume that tan(n) is irrational
for all integers > 0, thus for function floor(tan(n)) to have a fixed
point k, we have to have tan(k) > k, right?

I guess a Magma program like https://oeis.org/A088306/a088306_2.txt
would be needed to search thru larger values, and also the negative side.

Best,

Antti

>
>
> Ystävällisin terveisin,
>
> Antti
>
>
>> Veikko
>>
>> Antti Karttunen kirjoitti 26.5.2015 kello 14.21:
>>
>>> 260515
>>