This was generated via Monte Carlo Method (MCM) over many hours of computer program run time using a program I made especially for this and only this.
I then spent two whole days trying in vain to find the formula for it and now given up trying but hope someone here smarter than me might be able to find it.
I tried wolframAlpha it but for some reason wolframAlpha gives me only complete gibberish with this input.
The MCM outputs a floating-point real number estimate representing the integer and that real number is then rounded off to the nearest odd-number integer (notice that all of these numbers are odd numbers) and that estimate becomes less and less reliable as the input value increases so I have only shown the first 11 output values because I only consider only the first 11 to be sufficiently reliable.
I have reason to think that factorials may be in the required formula.
This was generated via Monte Carlo Method (MCM) over many hours of computer program run time using a program I made especially for this and only this.
I then spent two whole days trying in vain to find the formula for it and now given ...[text shortened]... e sufficiently reliable.
I have reason to think that factorials may be in the required formula.
The first 4 terms follow the rule T(n) = 3T(n-1) - 4. This breaks down as 29*3 - 4 is 83. So not tremendously helpful I'm afraid. Why are you rounding to odd numbers?
Originally posted by @deepthought Why are you rounding to odd numbers?
only because I noticed the first 10 are definitely odd numbers and I made the assumption that that is no mere maths coincidence so assume they are all odd to make it easier to guess the last one on that list which was difficult to round off as this was reaching the practical limits of what I could do with MCM. As I so often find with MCM, as the input value increases, the output value becomes harder and harder to reliably estimate and requires more and more hours of computer run time so I have to sometimes risk making some simplifying assumptions to squeeze out the last few output values in the hope that makes me see the pattern.
Originally posted by @humy only because I noticed the first 10 are definitely odd numbers and I made the assumption that that is no mere maths coincidence so assume they are all odd to make it easier to guess the last one on that list which was difficult to round off as this was reaching the practical limits of what I could do with MCM. As I so often find with MCM, as the input value in ...[text shortened]... assumptions to squeeze out the last few output values in the hope that makes me see the pattern.
So you are sure about all but the last one presented? Especially that none of them are off by one?
Factorial seems unlikely as the series doesn't grow all that fast. Also, the first 4 of these are prime. Is the sequence bounded by exponential functions (ie a^n < T(n) < b^n)?
Originally posted by @deepthought [b] Also, the first 4 of these are prime.
maybe that is a clue!?
But I will have to look into that later.
If these numbers are something like prime numbers then, just like with prime numbers, there may be no efficient way to derive the large ones. But any way to derive them would be better than no way to derive them.
But right now I think it looks like I probably going to have to (in my book) admit defeat on this one but fortunately this isn't for a problem that is too important.
I have already formulated solutions to all the really important statistical problems I researched and those solutions will completely revolutionize the world of statistics (and vary indirectly AI ) and some will show how a small part of the old conventional statistics is completely WRONG and show the correction; -this is particularly shown in the German tank problem as I can mathematically via proof-by-contradiction how the old conventional solution to the German tank problem is totally wrong and explain WHY, AND I will give the correct solution which has a totally different formula!
Removed
Joined
10 Dec '06
Moves
8528
03 Jan '18 14:43>
Originally posted by @humy maybe that is a clue!?
But I will have to look into that later.
If these numbers are something like prime numbers then, just like with prime numbers, there may be no efficient way to derive the large ones. But any way to derive them would be better than no way to derive them.
But right now I think it looks like I probably going to have to (in my book ...[text shortened]... ong and explain WHY, AND I will give the correct solution which has a totally different formula!
Six of them are prime in the sample you gave. This could be coincidence as all primes are odd.
Originally posted by @joe-shmo Six of them are prime in the sample you gave.
P,P,P,P,NP,NP,P,P,NP,NP,NP...
I find it hard to imagine that being 'mere coincidence' (an abuse of the word 'coincidence' ) i.e. being just a red herring.
The sequence may be somehow prime-number-related.
Some time after when I finally have my book published and show this unsolved 'humy problem' along with several other "Official unsolved humy problems to-be-solved" that I will list in my book and also explain in my book exactly HOW that sequence is generated (which is via an extremely complex algorithm with probabilities at its output maths limit), I hope eventually some real maths genius (probably have to be smarter than any of us here) may work out the formula for it and hopefully publish it and then finally we will all know.
Originally posted by @humy I find it hard to imagine that being 'mere coincidence' (an abuse of the word 'coincidence' ) i.e. being just a red herring.
The sequence may be somehow prime-number-related.
Some time after when I finally have my book published and show this unsolved 'humy problem' along with several other "Official unsolved humy problems to-be-solved" that I will list in ...[text shortened]... ere) may work out the formula for it and hopefully publish it and then finally we will all know.
I had a look at a list of primes and they are all of the form p, p+2, or p+4, where p is prime. I'd suggest running your programme again for the smallest of these (85) with a longer runtime and a different random number seed and check that it converges to 85 and that you don't get 83.
To see if they're exponentially bounded take the log of each one and see if you can bound the resultant sequence with straight lines.
Originally posted by @deepthought I'd suggest running your programme again for the smallest of these (85) with a longer runtime and a different random number seed and check that it converges to 85 and that you don't get 83.
I am afraid I already thought of that. It is definitely 85 even if allow heavy bias for absolute maximum margin of error.
I run the program several times for each output and with increasing number of iterations. In all cases, I did the last 3 runs for each output with no less than a massive 1,000,000,000 MCM iterations which is why it took so ridiculously long.