Friday, March 27:
This morning:
Saturday, March 28, 2020
Thursday, March 26, 2020
Bare necessities
Our last grocery shop was on March 11 at the local Real Canadian Superstore. We only go every three or four weeks so it's important to stock up. Alas, already back then they had no bathroom tissue to sell. So on March 17 I decided to try a grocery delivery service, more specifically Grocery Gateway. There's a minimum $50 order so in addition to $30 worth of "Cashmere" I ordered some canned goods. At checkout, the website wouldn't recognize my credit card information so I opted to pay at the door. I tried subsequently to add my credit card information to the account but there was no way to do that. I'm still waiting for their email response to my query about it. But no matter, when the order arrives I'll tap the credit card so that I won't have to push the buttons.
The scheduled arrival for the order was this morning. I was waiting for it by the front steps. When the order was brought to me I asked about the tap limit. I think he said $50. Damn! My original order was for just over $80. But wait, where's the toilet paper? They didn't include it, which put my total owing under $50. But my tap didn't work for some reason so I had to push the buttons.
The scheduled arrival for the order was this morning. I was waiting for it by the front steps. When the order was brought to me I asked about the tap limit. I think he said $50. Damn! My original order was for just over $80. But wait, where's the toilet paper? They didn't include it, which put my total owing under $50. But my tap didn't work for some reason so I had to push the buttons.
Sunday, March 22, 2020
My 500th Leyland prime find
This morning, after a four-and-a-half-day wait, I found my 500th and 501st Leyland primes. The above graph extends what I showed for my 200th find. I have now surpassed Anatoly Selevich's 475 such finds that he computed from January 2003 to July 2011.
Generally, I'm happy with the ongoing search. My 54 dedicated Mac-mini cores have been supplemented in the last few months by 6 cores on my old Mac Pro and 4 on a more recent iMac, which have been working on interval #8 to gain time on the overall computation, the length of which I now realize I did not correctly calculate. More specifically, the three Mac minis that have been working the upper half of interval #14 since early October 2019 were thought to complete their task by July of this year. Instead, they will run for a full year, until October 2020. In effect, that pushes the overall expected spring-2021 completion date to the fall of that year.
Thursday, March 05, 2020
Primes describing digit position
On Monday, Éric Angelini posted this to the Sequence Fanatics Discussion list: S = 11, 41, 61, 83, 113, 101, ... with digits 1, 1, 4, 1, 6, 1, 8, 3, 1, 1, 3, 1, 0, 1, ... at positions 1, 2, 3, 4, ...
11 says: "In position 1 is a 1."
41 says: "In position 4 is a 1."
61 says: "In position 6 is a 1."
83 says: "In position 8 is a 3."
113 says: "In position 11 is a 3."
101 says: "In position 10 is a 1."
etc.
Of course, each added prime must be the smallest possible that has not already been used. There's a few early surprises hinting at things to come: 11, 41, 61, 83, 113, 101, 151, 181, 233, 223, 263, 293, 353, 383, 419, 401, 479, 467, 541, 1009, 599, 631, 661, 691, 727, 751, 787, 797, 809, 877, 907, 919, 967, 991, 9001, 1031, ... Term #20 is 1009 because to the end of term #19 we have 53 digits/positions and term #19 says that the next digit (position 54) is a 1. So we need a prime starting with 1 and 1009 is the smallest one that keeps the growing sequence truthful. Term #20 also dictates that in position 100 is a 9. So when we get to term #34 = 991, we now have 99 digits/positions and so the next prime must start with a 9. Why not 997? Because that says that in position 99 is a 7 and we already know that in position 99 is a 1. So we must travel all the way up to 9001 to keep things honest. And that may have repercussions when we get to position 900.
I eventually wrote a Mathematica program that seemed to work extending the sequence. But it was taking a long time finding term #1447. So I had a look at how far it had gotten. Term #1446 was 190901 taking up positions 7006-7011. Perusing the list of prior terms, I saw that positions 7012-7020 and 7022-7024 were already assigned with digits: 191737191?371... Stepping through, 19 is prime, as is 191, but these lie: position 1 is not 9; position 19 is not 1. Continuing, no more primes up to 191737191. Then we can try 1917371911, 1917371913, 1917371917, 1917371919, replacing the ? with 1, 3, 7, 9, but these are not prime either. So we attach the next digit, 3, and replace the ? with 0, 1, 2, 3, ..., 9. We need not go further than 5 because 19173719153, finally, is prime!
So I managed to figure out term #1447 before my program did! In fact, it would not have found it because I had my initial search go up to only 104395301. Here's a graph (click on it) of 1500 terms:
11 says: "In position 1 is a 1."
41 says: "In position 4 is a 1."
61 says: "In position 6 is a 1."
83 says: "In position 8 is a 3."
113 says: "In position 11 is a 3."
101 says: "In position 10 is a 1."
etc.
Of course, each added prime must be the smallest possible that has not already been used. There's a few early surprises hinting at things to come: 11, 41, 61, 83, 113, 101, 151, 181, 233, 223, 263, 293, 353, 383, 419, 401, 479, 467, 541, 1009, 599, 631, 661, 691, 727, 751, 787, 797, 809, 877, 907, 919, 967, 991, 9001, 1031, ... Term #20 is 1009 because to the end of term #19 we have 53 digits/positions and term #19 says that the next digit (position 54) is a 1. So we need a prime starting with 1 and 1009 is the smallest one that keeps the growing sequence truthful. Term #20 also dictates that in position 100 is a 9. So when we get to term #34 = 991, we now have 99 digits/positions and so the next prime must start with a 9. Why not 997? Because that says that in position 99 is a 7 and we already know that in position 99 is a 1. So we must travel all the way up to 9001 to keep things honest. And that may have repercussions when we get to position 900.
I eventually wrote a Mathematica program that seemed to work extending the sequence. But it was taking a long time finding term #1447. So I had a look at how far it had gotten. Term #1446 was 190901 taking up positions 7006-7011. Perusing the list of prior terms, I saw that positions 7012-7020 and 7022-7024 were already assigned with digits: 191737191?371... Stepping through, 19 is prime, as is 191, but these lie: position 1 is not 9; position 19 is not 1. Continuing, no more primes up to 191737191. Then we can try 1917371911, 1917371913, 1917371917, 1917371919, replacing the ? with 1, 3, 7, 9, but these are not prime either. So we attach the next digit, 3, and replace the ? with 0, 1, 2, 3, ..., 9. We need not go further than 5 because 19173719153, finally, is prime!
So I managed to figure out term #1447 before my program did! In fact, it would not have found it because I had my initial search go up to only 104395301. Here's a graph (click on it) of 1500 terms:
Updates:
Sunday, March 8: I have run into a second large term at #3868. Term #3867 was 301471 taking up positions 21005-21010. Positions 21011-21020 and 21022-21028 were already assigned with digits: 3713793719?9317373... So #3868 is 371379371929 and #3869 is 31737313.
Monday, March 9: This is now OEIS A333085. It needs a decent Mathematica program!
Wednesday, March 11: I have rewritten my original program to run significantly faster. In fact, the new version has already overtaken the number of terms calculated by the old one. Here's an updated graph.
Monday, March 16: I've reached 12000 terms and primes strictly greater than 700000.
Thursday, March 19: Maximilian Hasler has written PARI/GP code for this sequence which he says computes 10000 terms in a few seconds. Unfortunately, I haven't been able to get it to run.
Tuesday, March 31: I've decided to call it quits at 18000 terms. There was another spike at #16966.
Subscribe to:
Posts (Atom)