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

[Antti Karttunen]

Veikko Pohjola wrote in
http://list.seqfan.eu/pipermail/seqfan/2015-May/014917.html

>My point is that instead of random search one could simply accept my conjecture for the moment and focus to proving it (probably indirectly), as a separate project.

The problem in that is that my intuition says that such a proof is not
appearing any time soon (that there absolutely would not exist any
other fixed points for floor(tan(k)) than 0 or 1), although I guess
that statistically they are very very unlikely. (Look how fast
https://oeis.org/A249836 grows).

On the other hand, as the proposed new definition of A258024 is now:
"Natural numbers n such that the iteration of the function
floor(tan(k)) applied to n eventually reaches [the fixed point] 1 (or
any larger integer if such fixed points exist), where k is interpreted
as k radians."

and if we separately had, matching exactly your original definition:
"Natural numbers n such that the iteration of the function
floor(tan(k)) applied to n eventually reaches [the fixed point] 1,
where k is interpreted as k radians."

then we would have two separate A-numbers, from which we would not
even know whether they are duplicates of each other or not. On the
contrary, it is easy to sprout a new, more restricted sequence from
A258024 if such mythical extra fixed points > 1 are ever found, and
then mention there that "Differs from its supersequence A258024 for
the first time at n=<some really huge number which probably does not
even fit onto a single line>".

I understand that the new, more inclusive definition might mar a bit
the elegance of your original mathematical idea, but for all practical
purposes the sequence (and its first differences A258200 which I'm
keen to hear once it is accepted) is still the same.



>As for the potential proof, it should be remembered that also the number of levels of nesting is without limit. A quick intuitive playing with the potential of finding a case where nesting would not lead to 0 or 1 suggests a fictive loop where floor(tan(n)) returns to its value at some earlier level of nesting.

Thanks for pointing this out! I had completely overlooked the
potential existence of finite cycles larger than one. I added
respective comments to A258024 and A258022.


>As an example, between 0…10^5 to reach the limiting value (0) the deepest level required is 8 for n=18116.
>The approach is straight-forward: 18116, -168, -14, -8, 6, -1, -2, 2, -3, 0

Yes, please see the proposed new sequence
https://oeis.org/draft/A258020
"Number of steps to reach a fixed point with map x -> floor(tan(x))
when starting the iteration with the initial value x = n. "


Now, the negative side of Z with respect to these functions is still
unexplored. If anybody is interested creating analogues for A258020,
A258021, A258022, A258024 and A258200, but having definitions like:

"Number of steps to reach a fixed point with map x -> floor(tan(x))
when starting the iteration with the initial value x = -n."

"Eventual fixed point of map x -> floor(tan(x)) when starting the
iteration with the initial value x = -n."

"Negative integers n with property that when starting from x=n, the
map x -> floor(tan(x)) reaches [the fixed point] 0 (or any other
integer less than 1 if such negative fixed points exist)."

"Negative integers n such that the iteration of the function
floor(tan(k)) applied to n eventually reaches [the fixed point] 1 (or
any larger integer if such fixed points exist), where k is interpreted
as k radians."

the above two could also made to have their terms positive, like:
"Natural numbers n >= 1 such that the iteration of the function
floor(tan(k)) applied to -n eventually reaches [the fixed point] 1 (or
any larger integer if such fixed points exist), where k is interpreted
as k radians."

and then also the first differences of either of those two (or both),
whichever is more interesting for its musical or any other interest
potential.
That function floor goes towards the smaller nearest integer also on
the negative side makes these behave differently (from their positive
brothers), even though tan(-n) = -tan(n).



Best regards,

Antti

PS. Please keep my mail address on the list of recipients, because
then it is easier for me to reply, as I will not receive the mails
sent to the SeqFan-list only, until they have been collected into the
next digest.


> Veikko




On Tue, May 26, 2015 at 11:26 PM, Antti Karttunen
<antti.karttunen at gmail.com> wrote:
> 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
>>>