196 and Other Lychrel Numbers

Welcome to p196.org!

NEWS ARCHIVE FROM 2002.

12/30/02 I had asked Eric Goldstein for the address to his own site, and he provided me with this. It is a commercial site that has nothing to do with the 196 or Lychrel search, but the software he has given me is a perfect example of the type of work his company can provide. I give him the highest compliments for his work. After all... He wrote the fastest 196 app I have ever used so far!! He has listened to all of my requests and implemented them quickly. Maybe his company can do something for you.

Hey it's my site... If I want to promote a business, I have that option... :-) Besides, after all the Eric has done for me, linking to his company is trivial!!

12/29/02 I hope everyone is having a wonderful holiday season!!

My girlfriend took me to the computer store for Christmas!! I have replaced the 1.9GHz chip with a 2.4GHz. I also replaced the motherboard, so I could take advantage of the speed increase offered by the DDR SDRAM. It runs at 266MHz instead of the 133MHz, of the PC133 I was using. Very nice!!

Eric Goldstein seems to have finally figured out why his app was running slower on a Windows XP machine, compared to any other OS. As a result, he sent me his latest version, I have tested it, and it is indeed the fastest 196 application to date!! Congratulations Eric!! Since I coincidently completed the 66 million set today, Eric Goldstein's app is the one that is running now, heading for 67 million and beyond.

I have updated the Software Comparison page. The new numbers show the tests with the 2.4GHz chip.

Again, I hope everyone is having a great holiday season, and I hope New Year's is all that you hope for.

12/13/02 I have finally gone too far with this 196 thing...

:-)

12/7/02 18:45 Eastern Standard Time USA - 150,000,000 Iterations!!!

11/26/02 I've been very bad about updating the numbers on this page. Sorry. But I am still processing, even though I'm not spending any time on updating this site. I've been on the computer very little lately. I'll try to do better!!

11/2/02 A number of things have kept me from updating any of the pages recently... Some of them silly, some of them bad judgment, some of them "disastrous".

If anyone is looking for a new game for their PS2, I highly recommend "Kingdom Hearts" from Square Soft. It's the same people that put out Final Fantasy, and I think it is the game that has given me the most fun from the entire PS2 lineup. For more hours than my girlfriend could tolerate, I loved it, and now that I have finished playing it, I can get back to the rest of my life!! :-)

Too make very, very a long story short, I formatted my drive and lost all of the email that I have received since my monthly backup on 10/1/02!!! I have all my 196 data except recent email. I backup the 196 data at least weekly, and I made sure it was all valid, before the format. But not the 196 email.

As a result, I would like ANYONE who has emailed me recently to mail me again. Really, all I NEED is an empty email, so I can recover your address, but if there is anything you still have a copy of I would like you to just fwd it to me again...

Thanks!!

Oh... Did I mention that I wiped out the file that I had, that contained all of my passwords across the web, including this site?!?!? Note to self: Multiple, complex passwords are a good thing, only when stored on a separate disk!!

I was trying to get my Mame cabinet networked to my main machine using a wireless network. It seemed to be setup on the Mame cabinet, and it seemed to be setup on the main machine, but I couldn't get them to talk to each other. I had spent days trying to get it functioning, and in a moment of extremely poor judgment, I formatted my hard drives, in an effort to start from scratch, to get it working again. I loaded everything back up, and even that didn't work!! So I lost all of the email for nothing!!

Turns out, that it all can down to my own firewall!! In an effort to protect my machine, I had set the firewall to not allow any machine to connect to my main... So... It wasn't!! I wish someone would have included some comments about firewalls in any of the dozens and dozens of FAQ's and troubleshooters that I have read!!! It just wasn't something I ever thought about!! :-(

I started the attempt to get the two machines talking in SEPTEMBER!!! Here it is November, and I just got it all up yesterday!! :-(

So anyway... I think I'm all back up... I haven't missed any 196 processing time in the last couple weeks, since the machine was working, but I didn't reload my backups until today, for fear of messing something up in my madness. So... None of these pages got updated... Should be back to normal now...

10/17/02 125,000,000 iterations - 51,737,154 digits.

10/11/02 Interesting... Eric Goldstein wrote me today, with the following...

Hi Wade,

I just tested my program on a 2.0 GHz P4 on Win XP. I got the same symptoms you got!!

A fast shallow test, 1:06, and a slow deep test. The deep test ran in about 16 minutes, but it didn't run solely all the time. My conclusion is that there is something about Win XP that slows the app down. Since Eric S' app doesn't show these symptoms it must be possible to solve my problem by modifying the code. I only have to figure out what, where and how.

I'll keep you informed.

Eric.

There might be something in this, that we'll all like to know!!!

10/10/02 I have been spending a lot of time, playing with Ben's newest checker application ISF Tool. It has all kinds of "neat" things going on inside, like statistics of the number being read, a greyscale visual image of the number, a Discrete Fourier Transformation of the number, etc. Here is the image of the 1 million digit dataset in a 998x632 pixel image.

I know it looks like static, and to be frank, I'm kind of happy about that! Like I said on the Blackboard entry for 10/3/02 "I am relieved, not to find a face staring back at me or something like that!!!" :-)

Ben's app shows that the files are pretty darn close to being pseudo-random numbers. Regardless, I have been resizing and opening different files and closing and trying everything I could make the app do, to find some sort of pattern, not IN the file, but BETWEEN the files. I'm sure that there is no repetition in any given file, but now, I'm wondering if there is any "commonality" or "repeating pattern" when comparing one file to another. (I think I just came up with a new entry for my Wish List!!)

Like I said, one of the things that Ben's app shows is "statistical" info about a file. This is a good example from the 1 million data set. As I understand it, the vertical bars are relative to each other, not absolute values. That is O.K., because that is really what I would rather see.

The interesting thing is that if you look at all the data sets, you begin to see a "repetition" of the images. For example, if you look at the 4, 19, 20, 33, 36, 39 or 48 images, they all are remarkably similar in their distributions. The 0's and 9's peak well above the rest, and the numbers graduate into a nice valley shape. I see other distinct "repetitive patterns" in other datasets. (And although none of them look as "pleasing" as the 7 above... They are distinct...)

I ran the sequence of 55 consecutive iterations starting from 1 million digits. Then I converted them all to their "statistical image". So far I haven't found anything that I can put my finger on. (For example, they are not spaced evenly apart.) But the "patterns" are still there. I haven't "classified" them, but I would say that there are 6 patterns that exist. (That 1 million file from above is another of them.) It is difficult, because I don't know of anyway to REALLY compare them, other than loading them all into Paint Shop Pro, and rapidly scrolling them like a slide show. (But that LOOKS impressive!!)

So here is my theory and question to anyone who wants to answer it...

Any random (pseudo-random) file with enough digits will fall into one of those 6 general patterns. Is that true?

OR am I on to something and need to be spending even more time looking into this?!?

10/10/02 50,000,000 digits!!!!!!!!!!

Jason Kruppa from the United States sent me the following. I found it interesting. It is almost exactly what I was thinking about when I wrote the note on my Wish List. I have corrected a couple of typing errors in the note, but I am positive that I have not changed any of Jason's meaning!!

I remember reading someone's thoughts either on your site or on a Slashdot post that was talking about how a number and it's reverse, when added together, must not have any carries if it is to come out to be a palindrome. I thought that seemed reasonable, and didn't bother to pursue that thought. But yesterday I was looking on your pages and someone pointed out the simple fact that 29 + 92 generates carries, yet still comes out to a palindrome, 121.

That got me wondering what the patterns would turn out to be, so I wrote a little program to look for numbers that generated palindromes and had carries when performing a reverse-add. On first run I kicked out all the numbers that would lead to a palindrome that was the result of a carry, but that was not the useful data.

The useful data was when I did a single reverse-add on a number, checked for palindromicity (is that a word?) and checked to see if it generated a carry. That gave me the output from the attached file. Looking at that, you see that numbers have to be of the form:

"a1 b1 b2 ... c2 c1 d1"

or

"a1 b1 b2 ... 0 ... c2 c1 d1"

Where A1 and D1 total 11 (pairs of (2,9), (3,8), ...) and Bx and Cx have to be pairs totaling 11 or (0,0).

Using this information, it is possible to calculate the percent chance of picking at random an x digit number and having it be a single iteration palindrome that had carries.

I created a small excel2k spreadsheet (See Below) that shows this. As you can see, as the numbers get larger there is indeed a smaller and smaller chance of getting a number that's going to lead to a single iteration palindrome.

I suspect that your overall chance of an x digit number becoming a palindrome on the next iteration is the sum of this percentage and the percentage chance that the number will have no carries.

Anyway, I hope this is useful to you, or of some use in one way or another. If you'd like to discuss with me, let me know.

Jason Kruppa

Here is Jason's Excel data:

Number of Digits	Number of Single Iteration Palindromes With Carry	Percentage of Numbers that are Single Iteration Palindromes With Carry
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	8 8 72 72 648 648 5832 5832 52488 52488 472392 472392 4251528 4251528 38263752 38263752 344373768 344373768 3099363912 3099363912	0.088888889 0.008888889 0.008 0.0008 0.00072 0.000072 0.0000648 0.00000648 0.000005832 5.832E-07 5.2488E-07 5.2488E-08 4.72392E-08 4.72392E-09 4.25153E-09 4.25153E-10 3.82638E-10 3.82638E-11 3.44374E-11 3.44374E-12

His first column was simply the number of digits. His formula for the second column looked like this: "=8*(9^FLOOR((A2-1)/ 2,1))", with "A2" being the cell for number of digits. And his third column formula looked like this: "=B2/(POWER(10, A2-1) * 9)", with "B2" also being the appropriate cell...

I think this is very interesting, specially since it does something that I had already wondered about. Maybe someone else wants to comment??

10/9/02 Three quadrillion calculations.

10/4/02 I made a mistake in yesterdays note about Eric Goldstein's machine. Here are the correct specs for differences, as I know them... (If they're wrong again, Eric can let me know, and I'll correct them again.)

	My Machine	Eric's Machine
CPU: OS: RAM:	P4 - 1.9GHz Win XP pro 256m	P4 - 1.7GHz Win 2k pro 512m

Gives us the following test results:

Coder	My Machine	Eric G's Machine
Eric G. Shallow Test Eric S. Shallow Test Eric G. Deep Test Eric S. Deep Test Eric G. Very Deep Test Eric S. Very Deep Test	1:09 1:37 15:14 9:39 16:07 9:40	1:16 1:47 9:29 10:22 Unknown Unknown

I think this is accurate. I have tested, tested and retested both apps on my machine. My times are CONSISTENTLY within 1 second of each other. I'm sure Eric G.'s are also... Now, that I look at it all in one place, it strikes me as even more confusing...

Again, I ask... Anyone have any idea of WHY?!?

10/3/02 Ben Despres has written a program to do two of the things I had asked for my Wish List. He has written a checker app that runs under Windows, and at the same time, shows a greyscale image of the number being tested. VERY COOL!! If anyone wants it, it can be downloaded from his site: LOCAL MIRROR OF BEN'S SITE. He is adding the ability to save the image, and scroll to see the rest of the image, so he'll probably have those up in a few days, but the first version that he has sent me, is very fun to play with.

As I expected, the datasets that I have run through his app, look like static. Really, I am relieved, not to find a face staring back at me or something like that!!!

Jason Doucette has finished all 15 digit numbers for his Longest Delayed palindrome quest. You can see them on my Other People's Notes page. I should have had these up a couple days ago, but... Thanks Jason.

Looks like his Longest Delayed Palindrome is still 201 iterations... At least until 196 solves out!! :-)

Eric Goldstein sent me his app a week or two ago, and I was testing it for him. An interesting thing is occurring... Maybe someone can point something out to us...

On his P III - 1.7GHz machine, with his app, he is getting times faster than Eric Sellers. (Two minutes faster in deep testing, if I remember correctly.) On my P4 - 1.9GHz machine, he is slower then Eric S, by almost 6 minutes for the same test. (20,000 iterations from 10 million.) And about 6 minutes slower for the 5,000 iterations ending at 96,650,213 (which is 40,000,000 and up.)

The two differences that we have thought of between the two machines are that he is running Win 2000, while I am running Win XP pro. And that I have a P4 and he is running a P3. Beyond that...

Anyone have any idea of WHY?!?

I also noticed a new 196 comment on the kiro5hin.org site. The post here from Aug 9, 2002, claims to have taken 196 out to 250 million iterations... From the language of his post, I take it that he did this in one day!! I don't see anyway to contact him/her to try to verify that incredible statement. I'm skeptical...

10/01/02 No "news" to speak of...

9/27/02 Eric Goldstein is around 18.5 million... His program is getting faster and faster.

Eric Sellers still has the fastest program that I have tested. Now, it's working on 48 million. :-)

9/22/02 There is a new name on the Milestones page!! Eric Sellers' app was the fastest at the time I started the 46 million set, so I ran it. I had to make a decision during the 45 million set, how I was going to credit different software writers for a data set and when I would use a new app. I decided that whichever program I was running for a given set, would be the one to finish that set, regardless of whether I had received a faster one while it was in work. Then, when I started the next set, I would look at all of the programs, select the fastest, and use that one to completion. It seems like a good strategy to me. It seemed the most fair, and no one could argue with me over something like "My app did 55% and his did only 45%, so why didn't I get the credit?" I am positive that I would have never heard something like that from the current 1/2 dozen writers that I have apps for, but in the future... It seemed like a good idea to set a "standard".

As a result, Ben's app finished the 45 and Eric's began and finished 46. Now, Eric's is still the fastest one I have, so it will be the one I use to get to 47,000,000.

I interesting thing happened to me a week or two ago... Eric and I were "debugging" his app, and it wasn't giving the correct answer on some iterations, but was totally correct on others. we were kind of confused for a day or so. What really bugged ME though, was the fact that for a given iteration, I had two different numbers, and BOTH of them passed Ben's checker program. This brought to focus, that I didn't understand how the program functioned. Eric and Ben both explained it to me, and now I think I have a much better idea of what is going on, but it drove home one of Ben's statements, that he had made earlier, but I had forgotten, or maybe just ignored :-(

"This relates to what I mentioned to you about how the checker can prove *incorrectness* but not *correctness*. Passing just means it has the right MOD-9 value. Or, to think of it probabilistically, only ten distinct MOD-9 values exist (0 through 8). A completely random file therefore has about an 11% chance of "passing" the test."

So I learned something new... :-)

As it turns out, Eric's program was giving us the correct number for the odd iterations, it was just reversed. So, it SHOULD have passed Ben's checker. Eric has since "fixed the bug" and now, every time it saves a file, it puts the number in correct order. On to 47 million digits...

9/12/02 Eric Sellers sent me his latest app. He too has managed to improve his time. You can see them on the Software Comparisons page, as always. Also, an entry for Udo Zallmann. His app was slow, but I think most of it was due to the fact that I think he was writing to the disk EVERY iteration. :-( Check them out.

One of the things I LOVED about Eric's program, is that it saves a file with an "ISF" extension. It is his tribute to "Istvan Standard Formatting". I will use it as my default extension from now on...

In case anyone is wondering, Eric Goldstein of the Netherlands is currently around 12.8 million digits in his 196 search...

9/11/02 Chris Lomont (His page here) has done it again! This time pulling 2 min 20 sec off of the deep testing and 24 seconds off the shallow testing. Currently, he has the fastest app that I have ever tested. His times are: 0 - 413,280 iterations in 1:01, and 24,159,531 - 24,179,531 in 10:27. Amazing!! Hopefully, he will decide to send Ben a copy of his source code, so that the world can marvel at it.

Of course, I'm sure everyone would like to see Eric's code also. To see such a radical speed increase WITHOUT MMX!!

Ben?? Eric?? Time to kill a few more brain cells, and set the next mark to beat! :-)

I have also added a new page. The Wish List is a list of programs that I would write if I had the ability to do so. Since I don't, it is a list on this site. My hope is that someone will want a project other than a 196 app, and maybe will write one of these.

9/10/02 One of the things that I find interesting, that really has NOTHING to do with this site, is the fact that I average 1 visitor every day, because of the Alphabetic Palindromes page. Not for the fact that people are looking for alphabetic palindromes. No. I get one visitor a day because people are looking for love letters, and the title of that page is "Letters Need Love Too."

Consider today's visitor, who typed my love letters and Google ranked me 7th of 1,950,000 hits!! Or yesterday's which was a Yahoo search for love letters example, which ranked my page 3rd of 816,000 returns.

I mean the other queries found on the Extreme Tracker link at the bottom of this page make sense in one way or another, but LOVE LETTERS?!?!? For this site?!?!? Even though Google is my default browser home page, and it provides remarkable results, it still seems like more work needs to be done in the search engine arena. Of course, maybe one of those people looking to plagiarize love letters to send to their soul mate, might the one who has the background to solve the 196 question once and for all, so who am I to question my visitors???

But I still find it interesting...

Sorry about this update... It was a lllooonnnggg day at work... :-)

9/9/02 It looks like, I will have to adjust my "shallow iteration" testing again... 413,280 iterations is going to be getting harder and harder to compare, if the future keeps pace of last couple days!!!

Chris Lomont has managed to pull another 18 seconds off his shallow run and 1 minute 58 seconds off of his deep iterations. The app I have right now, stands at 1:25 and 12:48 respectively. So at the moment, he is the fastest in the shallow iterations, and still second in the deeper iterations. (I've updated the Software Comparisons page yet again.)

He and I were confused by the fact that his tests on his P3, 1GHz machine showed a doubling of the speed between the two latest apps, but my machine (p4 1.9GHz) only showed about a 15% increase. The mystery seems to be solved by the following comment from a note of his today:

I just realized on your system it will perform at 1/2 speed due to my threads :) I have a dual processor. I will make the code only use one thread, and that should give you a good speed increase. When I run it at school on a single processor it uses only 1/2 CPU time. So that should double.

TWICE as fast, as what he has already sent?!?!

I am anxiously waiting...

9/8/02 Holding steady at 107,407,247 iterations... I deleted my 44 mill number, and am forced to run 43-44 a second time to get it back! I'm sure you understand I was MAD!!! When I "recreate" 44, I will continue from the above mark, and be back on track.

A VERY interesting day... I have not only tested a new application from Eric Sellers of Canada, but also a new one from Chris Lomont from the US, who is completing his PHD in math.

Chris' application was very interesting, from the point that it had a lot of "other" functions in it, other than simply a 196 search. It was also VERY fast!!

Eric Sellers of Canada... compact and fast, That is the best way to describe it.

It looks like there may be a new king of the hill. All of the numbers:

Test	Ben	Eric	Chris
0 - 413,280 Iterations 24,159,531 - 24,179,531 Iterations	1:33 15:23	1:58 11:35	1:43 14:46

So Ben was still quicker in the low end, but as the numbers got large, Eric and Chris began moving away. Eric credits this to the fact that he is using 1/2 the memory as Ben's application. Chris didn't give any indication of what he had done.

NOW... With my limited knowledge, and the way that people have explained it to me, during these tests, what amazes me, is that Eric did not use any MMX functions for his speed increase!!! I haven't seen his code, and I doubt it would mean anything to me, even if I did, but I'm hoping that he will send a copy of it to Ben. I have a feeling that he has discovered some amazing new flip and add routine, that if it were combined with MMX functions... Well... You see where I'm going... :-)

Eric still has to finish the "eye candy" end of things. Saving at specific iterations and digits, beginning from different numbers, etc. But I doubt those functions would hurt the performance. (Would they??) (and if they did... Eric, LEAVE THEM OUT!!)

I believe Chris's app is complete. Although there are still some questions I have asked him, that I'm waiting to hear back on.

When everyone gets back to me, I'll test everything again. But one way or another, there might be a new name on the Milestones page for 45 million...

I think everyone is with me, when I say "Great Job" to Eric and Chris!!

9/6/02 A 44,444,444 digit number occurs at iteration 107,382,665, and the first 25 digits are on the File Verification page.

9/3/02 At a suggestion from G.S. Chong, I have retested the applications that have been sent to me, and redone the way I will report the results. Instead of testing for a specific TIME length, G.S. suggested that it would be more accurate to measure the time to get to a specific ITERATION. So from now on, I will time the apps from iterations 0 - 413,280 and from 24,159,531 to 24,179,531. The 413,280 is a TOTALLY arbitrary iteration which happens to correspond to 171,104 digits. This will give me a very quick look at what to expect. The 24,159,531 iteration corresponds to 10 million digits, and 24,179,531 is simply 20,000 iterations above. That should give me a better idea of one program compared to another, when the numbers are starting to get pretty large. If someone can think of better numbers to use, explain to me why I should change, and I probably will...

I've made the changes to the Software Comparisons page. I'll try to get the rest of the info up soon!!

The other thing I noticed, that has little or no relevance to anything, is that the precision of The Ratio is getting more and more refined. It seems to be consistent to 4 decimal places now. This is I think what everyone expected, and not surprising, but it is something I noticed. Specifics are probably best seen here.

8/29/02 Doug Hoyte has sent me a 196 program and I have forwarded it and it's source code to Ben. My testing tonight showed that it turned out 835,072 iterations and 346,012 digits in a 30 minute run from 0. Of course, looking at the Software Comparisons page, it's easy to see that in 15 minutes, Istvan's program was far faster, and Ben's at 1,032,282 iterations and 427,640 digits is in no danger yet of being replaced. A huge thanks to Doug for his effort, anyway. Maybe he'll take it as a challenge. :-) UPDATE: 9/6/02 As seen on the Software Comparisons page, Doug's version 2 was considerably faster, and is currently in the Number 2 ranking, being faster than Istvan's. Great job Doug!!

8/27/02 I had some free time this evening, and was scrolling through the Lychrel Numbers between 0-1,000,000,000. I noticed, that between 100,000,000 and 200,000,000, the last digit of each Lychrel number seemed to be considerably more 4's and 6's than anything else. So I started looking a bit closer. Between 0 and 100,000,000 the numbers look fairly scattered about. Nothing that really stood out at me. Then there is a majority of 4's and 6's from 100,000,000 to 200,000,000. Then, every Lychrel number between 200,000,000 and 1,000,000,000 ends in a 9.

This led me to wonder what the most common last digit really was. I opened LabView, spent about a 1/2 hour testing around, until I was sure it was working correctly, then let it go on the Lychrel list 1e9. I expected that 7, 8, and 9 would be the easy winners. With 9 having far higher occurrences than anything else. But as with so many things during this quest, I was surprised...

I watched the counters closely, and even though they are moving quicker than you can SEE, you can get a "feel" for what is going on. The things that struck me, were that there were only about 475 4's below 100,000,000. Most of the other counters were in the 2,000 to 3,000 range. (I don't know the specifics. like I said. this was mostly "feeling" what was going on, although the numbers are fairly close.) 0 and 1 were in the 1,000 range... Then as I crossed 100,000,000, the six counter started racing, and the 4 counter started following. just about everything else moved, but very little. By 200,000,000, the number of 4's and 6's had almost tripled. Then, crossing above 200,000,000 nothing moved again that I saw, except 9's.

The final numbers look like this:

Ending Digit	# of Occurrences
0 1 2 3 4 5 6 7 8 9	1,527 2,211 2,548 3,000 1,129 3,133 5,343 3,913 3,946 4,964

Nothing is as lopsided as I expected. There were only around 2,800 9's at 200,000,000. The rest of them were made up all in a row, at the end of the file. And in fact there are less 4's than any other number, and more 6's than any other number. I'm curious...

In the end, there is probably no value to what I did this evening, but I killed some time, and maybe it makes sense to someone. Or maybe there is something there after all, we just haven't seen it yet.

I can't wait to get a look at the 1e10 list...

8/25/02 I have made minor changes to almost every page on the site. There has been a wonderful influx of ideas and information coming to me from many people since the Slashdot article. A lot of the changes are very minor, but people seemed to want/need them to clarify certain points. I hope I got everyone's inputs correct!!

Beth Cooper and Chun Yi asked to see the spreadsheet that I mentioned somewhere on the site, that I use to track the status of my progress. I don't know if anyone else is interested, and I don't even know what value it could be to someone, but here it is in a zipped Excel file. Maybe there is value to people like Eric Goldstein, who is verifying all of my work, by running 196 also. (Currently, he is around 10 million.) I don't intend to update it except maybe rarely, but it is current as of this afternoon. Anyway... It is there if someone wants it. If nothing else, it shows a really nice "timeline" of how I have moved forward!!

8/21/02 I am a chowder head again, and it took Mr Eric Sellers to point it out to me...

Eric noted that the numbers I had on my Software Comparisons page, didn't quite match up with the results on The Ratio page. It seems that I transposed Istvan's iterations with Ben's digit length, resulting in a ratio of around 1.7 and 1.8 for each application. On top of that, when I ran it again, to verify the iterations and digit length, they weren't even correct for Ben's app!!! I must have been sleeping when I did that!! I have corrected it now, and feel completely and properly chastised for my error. Many thanks to Eric for noticing that!!!!

It really is nice to have so many fresh eyes looking at the site...

8/20/02 I seem to have survived the Slashdot effect. Looks like the visitors are tapering off fairly quickly at this point. For Sunday, Monday and today, there were around 13,000 visitors to the site. Those of you who came back for a second time, I'm glad you did. Those of you who will never read this sentence, because you thought there was no point in this, well...

I think I replied to all of the email that I got. If you sent me a message, and didn't get a response, write me again, please. I will write you back.

I haven't heard if Ben or Jason or anyone else got anything interesting from the links off my page, but I'm sure I will in the next few days. There were quite a few very interesting emails that I got though. I'm really not sure how to put out some of the ideas and thoughts that I received... Maybe the best place will be to add them to the Other People's Notes page. Yeah, I think that will work for now. If anyone sees their note on that page, and wants it removed, let me know, and I will remove it immediately.

It almost seems like a small thing after the excitement of the last few days, but iteration 101,476,346 contains a 42 million digit number. :-)

I know there is more that I wanted to mention, but it escapes me for the time being...

8/18/02 p196.org has been listed on Slashdot!

I've put a very quick FAQ here. I'll add to it as I get time. or as I see more of the same questions being posted.

Reading through the posts, there are a lot of people that want to know what the point of this all is. Well, what's the point to figuring pi to the millionth decimal? What's the point of a lot of things? Math theory seems to rarely have a point in the beginning, but sooner or later, someone might find a use for any given problem. Someone posted that maybe there would be uses for something like this in encryption, because of the huge numbers that have been generated. I don't know. This is something that strikes me and a few others as interesting, and we're following it, by giving time to it. There isn't really a point, except that no one else has done what I and the other people listed on these pages are doing. If you need anything other than that, sorry.

There were a few posts about people wanting a more "theoretical approach" instead of the "brute force" method that we are using. I can only speak for myself, but I am NOT a math wizard. I state that over and over again in these pages. If I thought I could find a solution theoretically, I would have already done that. As far as anyone listed on these pages knows, there is no proof ever yet developed that answers the question of whether 196 does or does not form a palindrome. We're doing only the testing we can think of and implement for this problem. We welcome anyone who has the knowledge or interest to help us.

DennisZeMenace said we should make a fractal image of the number. Interesting thought...

Those of you who found the pages interesting, welcome. I'd like to hear from you. Those of you who can add any valuable thoughts or ideas to anything I and the others have done, I would like to hear from you. Those of you who think the entire thing is a waste of time, I thank you for stopping by anyway, I'm sorry you didn't enjoy yourself.

The incredible exposure that Slashdot has given on this tiny corner of trivial math, is welcome to us all. And at a minimum, my visiting country list has doubled in size in the last 3 hours!!!

Thanks,
Wade

Ben had posted to the article the following as part of a post:

Additionally, most Slashdot readers run Linux. Although I plan to write a Linux client, at the moment my optimized reverse-and-add routine only builds under Windows (mostly because I hate AT&T syntax assembler, I actually prefer coding for Linux otherwise). So, if anyone wants to volunteer to convert a 250+ line in-line assembler function (with MMX) from Intel format to AT&T, drop me a line (you would of course get full credit for your contribution).

That was followed by a post from bp33 that said:

> Additionally, most Slashdot readers run Linux.

Really? I don't want an OS flame war but wonder how you knew this.

I would like to comment that in my tracking, I was surprised to see the following:

Of the visitors that have hit the site today, Windows Users were 70.61% of the traffic, Unix (Linux) users were 21.46%, Mac users were 6.61% and other covered the remaining 1.3%. For all the blow and hype on Slashdot of Linux and how everyone seems to bash MS all the time, looks like most of them are Windows users! (I'll never read Slashdot with the same slant again!!

8/16/02 10:12am EST: It took around 2,069,427,300,000,000 calculations and who can guess how many hours, to reach 100,000,000 iterations, resulting in a number 41,388,546 digits long. But now it's been reached and still no palindrome forming from adding and reversing 196. What a major milestone!!

Again, I've moved old news to the Blackboard Archive. (If that wasn't obvious!! :-) )

8/13/02 2 quadrillion calculations passed yesterday. All that time to perform the first quadrillion, then the second is performed in just over 5 months. They will accelerate relative to the million digit milestones. Next stop, 10,000,000,000,000,000... :-)

I also was thinking about Ben's email dated 6/30 found here. if all numbers become Lychrels by 1E28, then every new number I generate in the 196 search will be a Lychrel Number in itself, and 196 will in fact never solve out. Just kind of a logical thought... (And a sad one in my opinion!)

With that in mind, Ben is close to having a working "rough draft" of his Lychrel Search program. There has been a lot of "technical" email traffic between Ben and Jason with me sitting on the side watching... :-( I'll post here when Ben finishes and Jason puts it on a server. Then everyone who is interested will be able to help solve the Lychrel set for 1E10 and up!! If anyone wants personal notice, let me or Ben know so that we can send you an email as soon as all is running.

8/6/02 Eric wrote again and commented about yesterdays post like this:

The fact that the milestones start with a 1-digit is easy to explain. I mean, if two numbers of length n are added, giving a result of length n+1, the first digit of the new number is always a one. Try it with two one-digit numbers...

The weird thing is that you have four exceptions on your verification-page...that is not possible!
Unless those exceptions are not the FIRST occurrences of their digit-lengths.
Another thing is that two of the four exceptions are not million-milestones, but even then, it is still not possible.
You may want to verify your verification-page...

Hmmmm... I should have seen that explanation of the "1"'s coming!!!!! I'm a chowder head most of the time!!

As far as the 2,000,004 set, what is listed is in fact the second iteration of 2,000,004 digits. I stopped on that particular iteration, because that was the file that Tim Irving and Larry Simkins published on John Walker's page and I could compare the files.

The same thing happened with the 14,000,008 digit number. It is the second iteration for the stated digit length. I had a file from Jason Doucette's application, and when I switched to Istvan Bozsik's, I again stopped on a specific iteration, instead of the first occurrence of the milestone.

For the 30 and 35 million sets...

I know Istvan's application used to save every iteration and I would only save the first one. You'll notice that all of the datasets I reported on my Blackboard, that had been gotten with Istvan's program, made mention of how many iterations produced the number.

I had questioned Ben before about how his application saves data, because I didn't seem to be getting multiple iterations for the same dataset, as I was with Istvan's program. He replied that it saved all iterations that had the same digit count. I'll say this... In small files it saves every iteration that results in a given save point. HOWEVER I just played around with it, before I wrote this, and there are times when it was not saving every iteration. It was always saving at the specified number of digits, but in the case of 14,000,008 for example, there are three iterations that have that number. It saved the first and last, and skipped the second. Which coincidently enough was the one I was looking for!! It saved XX,792, and XX,794 but skipped XX,793. I ran it 3 times, and it did the same thing each time. I had to set a save point on the iteration, XX,793 to see the data. I don't know how to continue checking some of the higher numbers, without spending the time to re-run the datasets. But as long as it ALWAYS saves at least one of the iterations that produce a given digit count, personally, I don't really care... When you get down to it, for the 196 quest, a "39,000,000 digit milestone" is totally irrelevant on the next iteration... I separated them by million digits, because that is what everyone else has always done and seeing dates is an interesting way to show progress in the quest..

I doubt that I'll spend the time re-running the 30 and 35 datasets to find out. I am confident that they are correct for their iteration, even if they turn out to, not be correct, for the first iteration of the milestone. When Eric gets there, he can let us know... :-)

8/5/02 Eric Goldstein wrote me, and pointed out that I had mixed up the number strings for the first 25 digits of 5 and 6 million, on the File Verification page. I can imagine his heart skipping a beat when he checked his 5 million result, and it didn't match what he had!! Sorry Eric. My fault... (The page has been corrected.)

Eric also pointed out the curious discovery that all of the milestone numbers except 2, 14, 30 and 35 million, all begin with a "1". I looked, and there is a general trend for "7", "0" and "5" to be the second digit but I didn't do anything other than scan the list... Anyone have a comment about the 93% occurrence of "1" as the first digit??

8/4/02 Things have been fairly quiet and steady recently, so there hasn't been much to write. The iterations and digits are marching upward. I am actually more excited for the milestone that will occur in the next couple weeks, than the one that will happen in a couple days. A couple days from now, I'll cross 40,000,000 digits, but in a couple weeks, the 196 quest will cross 100 million iterations!! It's like a birthday!!

On a recommendation from Jason, I have changed the traffic tracker to one called EXTREME TRACKER. Again, this is only for my personal curiosity about visiting countries more than anything else, but some of the other details are neat. I am convinced the REAL TRACKER was the source of the pop under ads I kept seeing. I'd get 4 or 5 of them sometimes, by visiting MY OWN WEB SITE!! If there isn't something fundamentally wrong with that, I don't know what is! I'll see what happens now...

In case anyone else cares, there were 1,976 unique visitors seen by the other tracker. And by far, John Walker's Three Years of Computing, had generated more visitors than any other site. Patrick De Geest's World of Numbers is easily the number 2, then probably Jason Doucette's World Records page in third. The rest were off and on, or scattered across "sub-pages" of one of those three. I'll be interested to see if it continues that way.

Ben is working on a distributed computing, Linux coded, Lychrel search program, as he gets time. If anyone wants to run it, let him or I know. Jason is helping him, and providing some of his own code for the project, and just as importantly, if not more importantly, may let the program run from his server. I however, am unable to help very much to either of them, except to offer moral support and my thanks. :-(

Again, Thanks guys!! I can't wait to see where it leads us...

Eric Goldstein found that his program is doing correct math, by starting over again from 0 and running to 1,000,000. His answer matched the file I sent him. So, like me, something must have happened to one of his save files somewhere along the way. Ben's MOD-9 discovery has shown it's value yet again!! I don't know for sure, but Eric's last note to me said that he had some ideas, and was going to begin a serious attempt to overtaking Ben's application for speed. I hope for everyone's sake he suceeds!! (Although I think Eric wants his name on my Milestones list, and I doubt he'll let me run his faster program for my own work!!)

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

Eric, if you can catch me, I'll be only to happy to put your name on that page!! ESPECIALLY if your program is fast enough to overcome a 40,000,000 digit head start!!

We'll wait and see about all of these things...

7/30/02 Some of the times I have been accessing this site in the past week, a pop under ad has appeared for "Top Searches On The Web". It can only be closed from the Task Manager in Windows. I promise you, this is not by me. If anyone else is seeing this banner, let me know. I have a suspicion that it is the Real Tracker link that is causing it. I have been having other "strange" events happen lately though, so I'm not sure if it's just my machine or not. If anyone else is seeing it, I will remove the script immediately. I hate the damn things and I don't want one on my site, especially without my permission!! Let me know...

If anyone can think of something to replace Real Tracker with, that's free, I'd like to know that as well... I'd like to still be able to see visitors and visiting countries, but it's not as important to me as keeping the site free of that annoying pop under ad!!!

7/26/02 I have gotten mail from a gentleman in the Netherlands named Eric Goldstein. He has completed 196 to 23,000,000 digits. The trouble comes in, that his numbers and mine don't match! His iteration was 4,277 before mine, and his first and last 100 digits are not the same. he was generous enough to save his file on the web someplace, and I downloaded it to look at. I loaded it into Ben's program, and got the error message "MOD-9 checksum failed. The stored number cannot occur on the stored iteration.". Hmm... That's not very good...

I sent Eric my deepest sympathies. I have recently been in the same position, and understand probably better than most, how he must feel!! He is trying to figure out what happened. I hope to hear back from him soon. Eric, GOOD LUCK!!!

Now, it seems to me that there have arisen quite a few people lately working on the 196 quest. I think this is great, since it allows everyone a chance to share code as Ben is doing on his page, or to compare dataset numbers as Eric and I have just done. One of the things I thought that I would do to contribute to this increase of comparison, is to post the first 25 digits on all of my files. That might help someone figure out that they are on the correct path, or where there is a mistake, if one exists. So there is a new page to this site: File Verification. Maybe it will help SOMEONE, SOMEWHERE. :-)

(Anyone want to work on 879, or 1997 instead of 196?? I'll give you a big head start, by sending my files... Both are at 10,000,000.)

Ben also wrote a small "verification program" that you can download from his page. The zip file includes a writeup on how it works, and the source code for the program. Check it out or read more about it on the new File verification page on this site.

And almost as a side note: 38,000,000 was crossed on the 24th. :-)

7/17/02 As has been noted before, people sometimes make a mistake somewhere along the way in the 196 search. Heck, I'm not different as can be seen from the blackboard posts starting with 5/29/02!!!

So with that in mind, I got to thinking about the work of Quan Yung, who I linked to on 7/6/02. I have written him, but as yet have not heard back from him. I'm sure I will, sooner or later...

Anyway... I loaded the 6 million data set back into Ben's application last night, and began running it up again. What I found was that Mr. Yung is at least on the right iteration for the digit length quoted on his post, and I'm sure, he has the correct number. In fact, there are three iterations that produce the digit length 6,651,918. They are 16,069,989, 16,069,990, and the one he listed: 16,069,991. My congratulations to Mr. Yung.

7/15/02 A note to Evgeni Nurminski: I got your note, but cannot reply. I keep getting the mail bounced back. I don't know why. David Gillies has a web site you can get his address from, and Ben Despres has David's source code on his site: LOCAL MIRROR OF BEN'S SITE. Hope this helps.

I also got a note from Chris Arkin of the USA. Chris, it is good to meet you. He and a few people with a background in number theory, are interested in finding a proof for Lychrel numbers. (To prove that they will or will not form a palindrome.) I told him I would be VERY excited to hear what they come up with. If he writes me again, and has anything interesting, I'll post it here, and probably mail it to everyone on the planet!! :-)

Till then, my "brute force" method will be in full swing...

Ben had an idea to distribute a new Lychrel program to get other CPU's involved in searching for them. Along the same lines as the SETI@Home project. I have been meaning to post it here, so that if there are enough people interested, he could decide whether it was worth his time to code the program. Chris Arkin said that he would be interested. If anyone else would be interested in a program like this, let me or Ben know. If there are a dozen or so people interested, maybe we can really move ahead in finding the numbers, and then there might be more data for Chris Arkin's work. (and Ben's and Jason's, and Istvan's and Patricks's and...)

Someone from the "Sympatico" domain in Canada was the 1,500th visitor to the p196.org site.

John Walker's link to the site has generated traffic that is second only to Patrick DeGeest's for total referals, even though Patrick's link has been up a lot longer. :-)

7/13/02 According to some work that Jason Doucette did, which can be seen on the Other People's Notes page, of all the numbers between 0 and 99,999,999,999,999 (all of the 14 digit numbers) that solve into a palindrome, it takes an average of 10.2401 iterations to solve. (Anyone want to check my math?!?) There is a LARGE spike on the second iteration.

Interesting that they fall steadily (and fairly regularly) to a certain point at 150 iterations, then none form for 150-180 iterations, then they start solving again. (It makes a nice looking chart in Excel. :-)) It will be nice when he finishes the 15 digit numbers, and we can include those. I would expect that it is going to take many more iterations as the digit length grows. His progress is 25% as of 7/2/02, and can be seen here.

It's also interesting to me to actually see the fact that almost 75% of the numbers did not form a palindrome!!

7/11/02 There is one iteration that forms a 36,000,000 digit number. It is 86,979,674.

7/7/02 !!!!! John Walker's Three Years of Computing has a new link at the bottom of the page. He has added a link under the title of "Ongoing News of the Palindrome Quest" which comes to the p196.org site!! All over the web are links to his site. Getting some of that traffic, could bring a whole new set of people bringing fresh ideas to our work!! I feel about as excited as I would be, if this site got mentioned on Slashdot!!

7/6/02 I had quite a bit of free time this evening... A couple new links to browse through... Nothing I am going to post on the links page, but someone might be interested to glance them over...

This one is recent: http://unicast.org/archives/000152.html. And who is it?!?!?

Jason sent me this one: http://www.iris.dti.ne.jp/~math/palindrome/1-9999/report.htm. I translated it in www.worldlingo.com from Japanese to English. The translation wasn't too good, so I didn't get too much out of it, but it looked like they had seperated quite a few Lychrel threads.

I also found this one: http://www.zientzia.net/artikulua.asp?Artik_kod=2239. But I don't even know what language it is in, so there is not much I can do with it. It doesn't translate in Greek, Portugese, German, Italian, or any of the other options that are on World Lingo. If anyone can read it, I'd like to hear about it. (Heck, for that matter, if anyone knows what language it is, I'd like to know that as well!! :-) I REALLY liked that artwork on the site!!! Update 1/3/03: Andrew Murphy was kind enough to mail me, and let me know that the language was Basque. Thank you Andrew!

http://www.mathpages.com/home/dseal.htm is the first time I've seen any "proofs" for Lychrel Numbers in other bases. I've seen notes on base 2, but this message has others.

These were new pages to me as I wandered the web tonight. Maybe they are new to you as well...

7/5/02 I crossed the 35,000,000 digit mark with iteration 84,563,227.

7/1/02 I have added a new "Blackboard" style page. It is called Other People's Notes

6/29/02 After last night, all I want to write is that iteration 82,145,364 is a 34 million digit number. :-)

6/28/02 There is A LOT of notes for tonight!!

First of all, I'm ALMOST back to where I was when I realized that my data was wrong. A month wasted!!

Den Despres has made the generous offer to post his source code for all to look at, prod, and generally poke with a stick. His "announcement" was this...

I have sent this to Wade, Jason, and Eric, Feel free to forward this announcement to others who may have an interest, or post it on personal web pages (though please not to any "major" sites, like a Yahoo group, my web site couldn't stand the traffic of even a "casual" interest ).

Okay, after a lot of consideration, I have decided to release my source code.

LOCAL MIRROR OF BEN'S SITE

If others seem amenable to the idea, I have made a page specifically for hosting 196-related code. Perhaps no one will care, but I figured, I consider myself an open source developer, and others have expressed an interest in sharing code, so I'll make the first move and give people a central location to share code.

I only put a "toy" program up, to illustrate the use of my flip-and-add routine. If anyone really wants to see my rather messy Windows code, I'll put that up too, but it looks quite scary. ;-)

I had made this general comment on this page back on 5/22/02. I was thinking that there are a number of very talented people trying to all achieve the same result, the fastest 196 program, but they are all writing the program over and over again from scratch. I wanted to have some place for anyone interested in coding a program, to lean on the shoulders of those that have come before. Maybe Istvan Bozsik has an idea that would make Ben Despres' program quicker, which would give Jason Doucette an idea, which would then be improved by Eric Goldstien... That kind of thing. I would have started the ball by releasing my code, if I were capable of writing any... :-(

I have sent Ben, the Linux source that was sent to me by David Gillies of Costa Rica. I never did get the chance to test his program. I asked Ben to run it through it's paces on his machine, just for curiousity. David, If you read this, I hope I still have your permission to "release" the code!!! If not, email me!!!

Ben has also completed the Lychrel list between 0 and 1 billion. (all 31,714 of them. counting numbers like 9,999) It is 550k txt file, so it is here in a ZIP file of 151k.

With that, he and I were talking about the newest list of numbers. The following conversation passed:

Wade > Anything interesting in there???

Ben > Only that Lychrels tend to *strongly* cluster right above integer powers of ten... I plotted them on a log/log graph, and they make nice strong pulses at regular (logarithmic) intervals. I don't have an explanation for that, except perhaps that at a power of ten a number has one more digit. Hmm... one more digit... I wonder if any "clustering" of which non-Lychrel non-palindrome-forming numbers occurs. I think I will look into that right now.

Wade > This makes sense to me... Your program eliminates most of them. For the same reasons that 295, 394, 493, 592 and 691 do not show up on the list. They are the same lines as 196. I would have guessed that we wouldn't see 20968, 30967... 80962, 90961 since they are the same next numbers of 10969. That will make it appear that they are all concentrated at the powers of ten.

... Or am I not thinking correctly?!?!?

Ben > Well, yes and no. *If* for some reason a fresh batch of non-palindrome-forming series begin with every increase in digit legth, then yes, this effect does indeed look like a natural consequence of selecting the lowest that forms a given series as a Lychrel.

However, I cannot see any obvious means of satisfying that condition, making this an "interesting" result until someone can find a really good explanation.

Basically, although I agree that lower values within a given digit length would tend to satisfy the requirements of a Lychrel sooner than high numbers, I don't see why they don't fall into pre-existing series in the first place... For example, 1675 results directly from 196 itself, and has four digits. What would prevent other four-digit numbers from converging on that same series? This finding seems to imply exactly that something *does* prevent four digit numbers from forming the same series as three digit numbers (and five from four, and so on).

If you find it useful, I've attached my graph of log/log Lychrel density (a windows .BMP file), it zipped up just wonderfully (to only 5k!). Not really pretty, but it shows the clustering very nicely.

Here is the graph:

Anyone else care to comment???

Ben seems to be noticing quite a few new ideas and discoveries!!! I'm glad his brain is turned on to thoughts of Lychrel Numbers and 196 right now!!! He is learning all sorts of interesting things!!

Enough for tonight. I need to digest some of this.

6/25/02 Jason found an interesting link that we all seem to have missed in the past. As he says in his note: It seems to have more information about the origin of the 196 quest. I guess it wasn't 1984 Scientific American, after all. Here is the link.

It says that there are 249 numbers below 10,000, but we know that almost all of those are iterations of only four Lychrel Numbers. 196, 879, 1997 and 7059. (For the record, no one has convinced me, yet, that 9,999 should be included in a list of Lychrel Numbers.) :-)

6/24/02 33,000,000 was crossed at the 79,731,034th iteration at 4:13 am Eastern time this morning.

I also got an email from a gentleman in the Netherlands named Eric Goldstien. He has been running a program to calculate 196 since January of this year, and is currently around the 22,000,000 mark. I do not know if he has a web page, or if he knew of this one before today, or if he knew I was running the search when he started his, or anything else about his plans, but it is always nice to get a note from someone new, and at 22,000,000 digits, Eric certainly qualifies as someone interested in the 196 search!!

6/18/02 77,314,955 is the only iteration to form a 32,000,000 digit number.

6/13/02 Someone from the United Kingdom (dundeecity.gov.uk) was the 1,000th visitor to the p196.org site at 5:25 this morning. :-)

6/12/02 74,899,358 is the only iteration that produces a 31,000,000 digit number.

6/6/02 There is one iteration that contains a 30,000,000 digit number. It is 72,482,579. The first of four iterations before I found the error was 72,483,743... Close, but not correct...

6/4/02 Ben let me know that he has taken the first 3,552 Lychrels (0 - 100 million) to 100,000 digits, and none reached a palindrome or converged on another series.

6/2/02 Here is what I found by running the 28 to 29 dataset again...

The number is the same in both cases.The iteration number is the same in both cases. (70,067,270) However at the end of my data file that I did the first time, I have this:

1000120
1000129
1000216
1000276
1000340

I don't know what it is. I don't know where it came from. I don't know anything about it. It looks like the begining to one of my tests for the first missing number in the set. When I run that search program, I ask myself for a final file name and a file to read. It is possible that I selected the same file for both. That doesn't make too much sense to me though. I have a 29 million file for missing first numbers, and it doesn't match these numbers. Also, when the program creates the new file to save, it overwrites anything in that file already. So this confuses me...

Anyway, it's obvious, that the five extra lines in the file are the casue of all my trouble. It fits with the error messages that I got. Then it was a simple thing for the application to just concatenate those lines to the file as if they were part of the 196 calculation. At iteration 70,067,271 everything was wrong, and it just got worse and worse from there...

I have a couple different backups. They all have these extra lines. I don't know what happened, but at least I understand why the number failed after 29,000,000!! That's something!!

Again, I am struck by the VALUE to all of us, in Ben's "mod-9" discovery... I probably would have gone on and on and on, and it would have all been worthless.

I've tried to be extremely careful with these files. I guess I wasn't careful enough... :-(

On to 30,000,000...

5/29/02 Ben Despres has made a remarkable discovery, that has stalled all of my 196 work for at least tonight. Let me explain if I can...

He has written a Version 2 of his application for me, and cleaned up a lot of the Windows oriented issues that I had problems with. While he was working, he decided that inserting a CRC in the data file would help detect errors in file saves. Sounds reasonable to me!!

Then and to me, MUCH more interesting was this, which I will just quote from his letter:

Second, I discovered a really neat fact about the checksums of the digits generated by flip-and-add... At any given step, the checksum of the result will equal twice the checksum of the last result minus a multiple of nine (that multiple just happens to equal the number of carries). At first I thought this may lead to a "proof" of Lychrelness, but I have given up that idea for now. *BUT*, it *does* lead to a really simple check of whether or not a given number could have resulted on a given iteration, including in some cases whether or not a number could ever have resulted from a given starting number.

Basically, if Cx equals the MOD-9 sum at iteration X, with C0 meaning the same for the starting value:

Cx = (C0*(2^(x MOD 6))) MOD 9.

Actually, three distinct cycles exist, with only the longest using MOD 6... {0}, {3,6}, and {1,2,4,8,7,5}. 196 itself has the longest of those cycles (and no, unfortunately I could not find any patterns between cycle and converging-vs-conconverging).

So, although the CRC will only detect *new* errors, the MOD-9 checksum will (possibly) detect errors that have already occured.

I thought this was an amazing discovery!! This will prove useful to anyone trying to verify that work on any Lychrel Number is accurate and complete. Now, let me tell you what I found...

I loaded the 34,000,000 dataset, and pressed start. I stared at the screen at the following message:

MOD-9 checksum failed.
"The stored number cannot result from the stored starting value."

Uh-Ohh!!!

I get the same message with the 33, 32, 31, and 30 datasets. However 29,000,000 gives the following 2 messages:

"Reported Lengh differs from actual length. Using actual length."

"MOD-9 checksum failed. The stored number cannot occur on the stored iteration."

Data sets 28 and below load and run with no message other than a CRC error, the first time they are loaded. (Ben warned me about this.)

Coincidently, the 29 dataset was the one I was working on, when I left Boeing, and started processing here at home. This brings the question of a problem in my file transfer, or GASP!! is there some issue in the Pentium IV...

DAMN!!! I've got to sort that out now, before I go any farther...

I hope everyone sees the benefit from Ben's discovery. This, in my opinion is an amazing "breakthrough". A job well done Ben!!

So for now, I've "halted" my work. I am going to start again from the 28 miilion dataset, and see how it compares to the 29 set. Maybe that will give me some idea of what went wrong. I'm just thankful I wasn't in the 50 or 75 million range when this was discovered!! I think I can recover to this point, (IF it is just a matter of doing 29-34 over again!!) in a few weeks.

There's also the possibilty that Ben's program is giving me a bad error message, although the coincidence of which dataset it is that is messed up, leads me to believe that, that is highly unlikly...

5/28/02 There is one iteration, 84,561,500 that contains a 35,000,000 digit number.

5/26/02 It' s been a busy day!! This is my second entry for 5/26/02, but the news warrants it...

Ben Despres has completed a rough working program for the Lychrel Numbers. He has sent me the first 1,900 numbers!!! We have some ideas to sort out, but I wanted to get this list posted as quickly as possible. I'll format the page and get it posted as a html file as soon as I figure out the best method, but for right now, you can get it here.

Some of the questions that need to be sorted out I don't feel I should make by myself. I would really like some input on these ideas. If I don't get anyone's opinion, I will try to decide the best answers...

1. Can a Lychrel Number be a palindrome? My initial thought is no. That seems like it defeats the "spirit" of the search. However, as Ben points out, Jason uses palindromes as starting numbers for his Longest Delayed search. If 990099 does not form a palindrome by reversing and adding it's digits, does that qualify? Again, my opinion is no, this should not be considered a Lychrel Number, but I would like other people to help me decide.

2. How many iterations should be reviewed before a number can be said to not form a palindrome? I hadn't given this a lot of thought before, but now it appears that I have to. This is the heart and soul of Jason's work. His comment to me in one of his last emails was that his program will keep a list of numbers that have not solved and verify that list over time. I'll try to explain, as I understand it... His program performs reverse/add cycles on a number until either it forms a palindrome, or reaches a "iteration limit". (I'm going to make up the numbers to try to explain.) Lets say the program begins with an iteration limit of 200. After searching all the numbers to 200 iterations, the program will take the highest known iteration (192 on his page) and multiply that by 1.5 (Again, I'm making all of the numbers up!! I don't know the values.) This 288, becomes the new iteration limit. All new numbers are searched to an iteration of 288 AND the existing list of suspected Lychrel's will be searched from iterations 200-288. If any turn palindromic, they are removed from the list. (as well as may be a new record for his delayed work!!) This saves the time of checking EVERY number to 288 iterations. The checking and rechecking of the numbers to higher and higher iterations seems reasonable to me, but it is back to my question. How many iterations should be searched before it should be included in this list? By the way... If I understand Ben's email correctly, he allowed all the numbers to progress until the answer was 100 digits long. When he was completed, he went back and carried them through to 1,000 digits. And as expected or not, the list did not change.

If you look at the archive entry for 1/30/02, you will see that I turned off the testing for a changed digit of 196 after 10.2 million iterations, without forming a palindrome. I'm sure that the larger the starting number, the more iterations that are going to be needed to form a palindrome. (That one started as 1,000,000 and ended a little over 5,000,000 digits.) This area needs some thought!!

I have more questions I'm sure, but for now, I want to look at his list in a bit more detail, and get this posted on the web. I'll probably write more tomorrow.

5/26/02 When I checked my email this morning, I had a new program from Ben. From his note: After verifying the algorithm itself, I worked on the Windows code to make it at least tolerably useable... At some point, I seem to have whacked (as in, an accidental keystroke, not a pointer problem) a single byte of a bitmask used by the addition routine itself. This broke it, as you noticed.

I tested it on a couple iterations, just to avoid any wasted time, then I loaded the backup file I had from last night, and let it run through the same path that Istvan's had, beginning at iteration 83,749,408 and running through till iteration 83,840,746. The digit count and numbers themselves were the same. I guess Ben's correction worked. :-)

The difference is that Istvan's program took around 10-11 hours to run through the 91,338 iterations and Ben's took 3 hours 51 minutes!! (I didn't time Istvan's application, but I had restarted it before I went to bed last night, and I'm pretty sure what time I started and stopped it.)

So there is a new speed king 196 application, and it's extremely fast!! Now I guess I have to go and rewrite the Software Comparison page. Anyone want to try and beat Ben's program??? I'm still acting as a tester... :-)

This also means that I am going to retire Istvan's application. It has served as the mark to beat for so long, and I have been lucky enough to use it for such a long time, that it's kind of hard for me to quit using it. It's kind of saddening. But for a 3x increase in speed, I'll change programs, and who can blame me?

5/25/02 There might be a new speed king!! Ben Despres has sent me a new 196 application that is considerably faster as Istvan's!! Initial testing of 15 minutes run time, looks like this:

Coder	Iteration Count	Digit Count
Istvan Bozsik Ben Despres	458,019 1,032,287	242,975 586,484

The reason that I don't say right now, that this is the world's fastest 196 application, is because there is a discrepancy between Ben's data files and Istvan's. The digit count is different for the two programs on any given iteration. (I didn't test iterations below 500 or over 350,515) I ran 6 or 7 tests, and got different answers each time. This is disappointing. (I'm sure Ben feels worse about it than I do!!)

I have to believe that Istvan's program is correct. I have compared it to too many others, to believe that it is wrong. Also, the 500th iteration of Ben's application doesn't match Jason Doucette's published 500 iterations either. Jason and Istvan both match with a digit length of 216, while Ben's has a digit length of 229. I just sent a note to Ben, before I wrote this update. Maybe he has an explanation. I hope to hear back from him soon. If he can fix the addition problem, and maintain most of the speed that he has now, it will truly set a new mark for other programs to try to match!!!

5/22/02 Remember that I said that my LabView program was "extremely, obnoxiously inefficient"?? It was very, very, very slow. Well, on top of that, it doesn't work. :-(

I have not been able to figure out how to make LabView add two numbers that contain more than ten digits, and get an ACCURATE sum!! Oh, it will add the two numbers, but about 1/2 the time, it gives me a negative number, or something like "4". That won't work... I think it is all a matter of the intended application for the program. It is more oriented to searching strings, writing data files that might be coming from an experiment, monitoring temperature, etc etc etc. It works really well for the "sub searches" that I do on the datasets, just not for this new task that I tried. It's a LAB program, not a math program.

So I turned it off.

HOWEVER...

I got a note from Jason yesterday. He is going to try to find the time to rewrite his Longest Delayed program, to have it search for Lychrel Numbers at the same time. He thinks he can improve the efficiency of his code, and add the new functionality at the same time. I'm excitedly waiting to hear from him...

Coincidentally, yesterday, I got a letter from a gentleman named Ben Despres. He lives in Maine in the US, and has offered to write a Lychrel search program, as well, as he has some specific ideas for improving the speed of the 196 program. I have sent him some "benchmarks" of Istvan's program, and he is working to see what he can come up with. Ben, I hope you succeed!!

You have to admit, that from my point of view, (or for all of us really) this is all very positive news!! We now have a couple of people attempting to write programs that don't exist yet, as well as searching for ways to improve the speed of existing programs. The "competition" might really spur these projects forward!!

I had asked both Jason and Ben about how it is possible to speed up the addition process. They both gave me some pretty technical explanations about how it might be done, and both of them agreed that there could be an increase of as much as 4-8 times what we have now!! What you would really get, seems a little open. I can only imagine running a program 4 times faster than Istvan's!!

I wonder if posting the source codes on this site would let people examine each others work, and improve their own work by mixing and matching the best parts of all of them??? David Gillies in Costa Rica has given me permission to post his Linux Source code on this page. Maybe I'll create a new section, and post it there. Does anyone even want to see it? Does anyone else want to offer their code to the world in an "Open Source" type environment? Istvan, I know you read this page frequently. Since you have the program that is the fastest, if someone asked to view your code, what would you think? You have given me a small section of it, but I've never given it to anyone else. Would you consider having it posted?

Nathan Moinvaziri, do you still visit this site? What do you think? Jack Driscoll... Any opinion? Anyone else??

I think everyone would understand if no one wanted to offer their code, but I also think that the entire Open Source concept is a good idea. I would give up what I have, but... I don't have anything. (Except some really huge text files. I think I would give those away if someone asked for them... I've never thought about it... I've never been asked for them... I do know that I'd be kind of disappointed for someone to use my own files as a starting point and beat me to 100,000,000 iterations while I was still working on the search. If I decided to quit the search, I'd give them away without ever even hesitating. Just as Jason and Istvan did to me.)

Regardless... I'm excited to see what Ben and Jason come up with!! I'll post more as I know it.

5/20/02 I have written an application in LabView to search for Lychrel Numbers. It is extremely, obnoxiously inefficient, but it has begun the search...

I figure that if someone writes a program for me, I'll end up dropping the one I built and using theirs, but there is no telling how long it will be until someone has enough free time to write a search program. So I decided to at least get something written that could start. I used the methods described on the Lychrel Challenge page. LabView is very poor at handling large numbers. On top of that, my "coding" is almost as poor as if I'd tried to write it in a different language. But like I said... It's something.

I'll post them as I find them.

5/15/02 There are three iterations that contain a 34,000,000 digit number. The first one is 82,146,096.

Who has time to write a program?!? Even if you do not have time to run it, does anyone have time to write a program to discover Lychrel Numbers? I know and have stated many times on these pages that I can not do it. So, I am kind of throwing this out as a challenge to all of you reading these pages. If someone will write the program, I will find a machine to run it on. Or, if you write the program and can run it, and want to send me the numbers, I will post them. You will get all of the credit as the discoverer (or as the code writer). As far as I can tell, the first 1,895 have been discovered. Ian Peters has a reference to them on his web page Here. I have sent him a note asking for a list of them, but have not heard back yet. I would have to give him credit as discoverer, but number 1,896 is still waiting to be found!!! Write a program, send me the numbers, get your name in history. More info can be found on the newest page to this site... The Lychrel Code Challenge

5/13/02 I tend to think about this 196 problem quite a bit. Recently, I have been thinking about all of the seed numbers that I know exist, and why they do not form palindromes. In the middle of my twisting and turning these numbers around in my mind, I realized that I have never seen a name for these numbers...

I mean there is a name for a number that is the same forward and backward. It's obviously "palindrome". There is a name for the types of numbers that are only evenly divisible by themselves and 1, they are "prime numbers". There are the words Integer, Fraction, Odd, Even, Factors, Mersenne Prime, and a whole lot more, that "Name" a class of numbers. But I've never seen one for the class of numbers that do not form palindromes. Not even on Patrick De Geest's wonderful site can I find a name. (Although I will admit that there is so much info on his site, that I sometimes get lost, and may have just missed it!!)

But assuming that I am the first person to think that these numbers need a name, I get to choose what I think the name should be, Right? So, until someone tells me that I am not the first person to name this set of non-palindrome forming numbers, I am going to call them LYCHREL numbers. (la-shrel).

Update your websites and spread the news. All together, we can add a new word to our languages and have a name for a very amazing set of numbers!!

5/11/02 I was thinking about probability and randomness the other day, and it made me start thinking about if the datasets could be called random numbers. I know that they are not actually random, because there was a distinct path to get to them, that could easily be duplicated by anyone, and they would get the same result as I did. But for a practical test, could they be USED as a very large set of random numbers?

Again, I fired up the LabView program, tried to figure out a test for randomness. The first thing I did, was build a program to count the occurrences of each digit. I assumed that in a random set of numbers, the digits 0-9 would each show up 10% of the time. This is what I wanted to test for.

The results look like this for the 1 million dataset:

0 - 105,335
1 - 97,694
2 - 98,116
3 - 96,807
4 - 100,954
5 - 101,360
6 - 95,821
7 - 98,976
8 - 98,693
9 - 106,244
Total - 1,000,000

Each digit shows up pretty much 10% of the time, (A perfect 10% would be 100,000 times each.) This test took about 15 hours to run, so I doubt that I'll run it on a larger dataset. I don't really think I want to spend 495 hours running the 33 million set!!

I'm still thinking of other tests that I could apply to show if the number is a practical random number. Not that I have any need for a 33,000,000 digit random number, but if I ever did, it would be nice to know that I have one that I can use already on my computer.

5/10/02 I've finished all of the searches for odd digit palindromes within the datasets. Back to crunching on 196...

5/7/02 5:19:48pm Eastern Time, USA. Someone from the domain "Shaw Communications" in Canada was the 500th visitor to the p196.org site.

5/6/02 If anyone has been paying attention to the counter above, you will have noticed that it has stopped progressing. I have TEMPORARILY stopped the 196 calculations. I mentioned last time, that I built a program to find odd digit palindromes within the datasets. This is what I've been spending the CPU power on for the last few days.

LabView really tries to grab 100% of the processor when it's running. It's not very friendly at multi tasking with another application. Especially one as intense as Istvan's program!!! :-) As a result, both programs were killing each other for CPU cycles. The results were pretty poor. Both programs suffered terribly. So I've turned off the 196 program, while I complete the search for odd digit palindromes within the datasets. It's taking about 9 hours to complete a dataset search. There are only about 11 more to do. A couple more days...

Once the Data Set Information page has been filled in with all the missing numbers, I'll turn LabView back off and get the 196 program running again. Go look at the data page. There are some interesting results on there that maybe someone can explain. I've never seen anyone comment on the results I found, so I can only assume that I have found something "new" that no one has thought of before... Comments?

While looking for other large number sets to compare, I found this page: Mathews: The Archive of Recreational Mathematics by Walter Schneider. I had done a Google search for "+million +digits" -pi" and after bouncing around a few minutes, found his page. Most of his information is a bit over my head, but it was really nice to see a lot of familiar names and links to web pages there. He even has mine listed as 30 million digits, so his page is updated regularly, or at least recently. (last updated 02.05.2002 to be exact) Mr. Schneider, It's good to meet you.

5/2/02 As you can see, I've archived the past notes onto an Archive page. I just felt that this page was getting too long. I keep adding to the top, and the page gets longer and longer... So I moved it. That's one of the joys about owning the page. I can move things around to fit what I think is a better layout. :-)

I've given a lot of thought to the layout of the site lately. It's growing quite large, and I keep thinking of things that I would like to put here, but it's also getting to be a bit cumbersome to manage. Every milestone has 4 or 5 pages that need to be updated or at least checked to still be accurate. Some of the info seems to go together, but I don't know what the simplest method is to display it all. I really want to keep the simple style, and fast page loads. Don't be surprised if everything moves around as I try to sort it all out. I'm also very open to suggestions if anyone has any. Anything you'd like to see, something that is stupid that should go away, a particular page, my colors? Anything that would make the page better for everyone, and maybe easier for me, I'd like to hear about it.

My machine has been "hanging up" for 30 or 40 seconds, every time I access the site. It sits and won't let me do anything at all, then it all begins working again. I'm trying to figure out why. The only thing I can think of, is the Real Tracker banner below. If anyone else is having a problem with the pages loading, LET ME KNOW!!! As much as I like looking at where people come from, I will remove the banner if it's slowing things down!!!

I have taken the time to build a LabView program to figure out the largest palindromes in the datasets that have an odd number of digits. I'll get the results of the searches on the Data Set Information page as I get them.

Some of the results are pretty interesting. It appears that in general, there are larger odd digit palindromes in a given string of numbers than there are even digit palindromes.

It also appears from my files that there are far more odd digit palindromes than even digit ones. For example, in the 7 million data set, there are 1,532 even digit palindromes with 6 or more digits, but there are 4,645 odd digit palindromes with 7 or more digits. I'm seeing results like this in every data set. Another example is the 33 million dataset, which has 4,110 even palindromes with 6 or more digits compared to 11,020 odd numbers with 7 or more digits.

Does this tell us anything about palindromes (or probability of numbers) in general? I'll think about it, and if I think of something, or someone writes me, I'll post it.

4/30/02 Iterations 80,535,060 / 80,535,061 / 80,535,062 / 80,535,063 and 80,535,064 all produce a 33,333,333 digit number.

4/26/02 There are two iterations that contain a 33 million digit number. The first one is 79,728,684.

4/17/02 There is a 32,192,735 digit number at the 77,777,777th iteration.

4/14/02 Iterations 77,311,782, 77,311,783 and 77,311,784 all contain a 32 million digit number.

4/12/02 There hasn't been any "news", so I haven't written for a while. Just updates to the numbers... And to the visitors page, as I see new countries.

I did get a note from Istvan Baktai. He also lives in Mezokovesd Hungary and happens to know Istvan Bozsik. Istvan, it was good to get your note and kind words. Thank you.

I figure about 2 more days to 32 million digits and maybe 4 till 77,777,777 iterations.

4/3/02 4:01am Eastern Time, USA. 75,000,000 iterations. (31,042,350 digits)

4/2/02 The 74,897,447th and 74,897,448th iterations both are a 31,000,000 digit number.

3/30/02 I got a note from Nathan Moinvaziri a couple days ago. (He didn't mention where he was writing from.) He sent me another 196 application to test. He believed that his program would be faster than anything I've got. I tested it out, and was sorry to write him back that it was in fact slower than Istvan's program. (Which is the only one I tested against.)

I don't know what Istvan actually did to make his program so efficient, but I still have to say that it is the fastest palindrome program that I've seen yet. Most of the others that I've tested have been considerably slower. Congratulations Istvan. You made a good one.

This all brings up an interesting question that I thought about while I was running Nathan's program, and is the reason that I haven't (and probably won't) run David Gillies Linux program...

At this point, does it really matter who's program I run? In my mind, with only 2.5330 iterations per second being turned out by the processor (Pentium IV 1.9 GHz) it seems to me that even some of the most poorly written code (like what I might write) would "keep up" with the best. The difference is apparent when the machine is just starting from 0, and is doing 2,600 iterations per second. Then, the efficient code would have to be better. But when the machine is spending the vast majority of it's time, just adding the string, again I ask... Does it matter at this point?!?

I think no.

I'm not saying that I don't want to continue getting people's applications. I like looking at the different approaches people take, to get to the same result. And secretly, I like the suspense, of testing, to find out if "this one" is going to become the new "king"!! But until someone writes a faster program AND writes a "conversion" applet, to read Istvan's 30.7 Million file, I'll just continue like I am... :-)

I've also added two new pages to the site. One to try to put things into perspective of how large the data sets have become, and another, announcing the countries that have visited the site, based on the Real Tracker data. The are listed below, or you can just click Here for Visitors or Here for Perspective.

3/22/02 I've crossed 30,000,000. There are four iterations that have a 30 million digit number. They are 72,483,743 through 72,483,746.

3/19/02 I decided that I wanted to use a faster server, and since the geocities ftp always gave me trouble, I decided to move to this one. While I was doing that, I decided that I would break down, and register a domain name for the site. In a tribute to Istvan's application, which has kept me going, I chose P196.ORG.

p196.txt is the file name that his app uses. It's the most current file in the 196 quest. I back up the saves and copies, but there is only one file named p196.txt. That way, I always know to be VERY careful, and not erase it. That would suck!! :-)

Then I added the tracker thing at the bottom of each page. It has some pretty neat statistic information. Just for my curiosity.

I got a note from David Gillies in Costa Rica. He wrote a 196 Linux app after reading these pages. He claims that it should be 14% faster, based on the testing he's done. I have a Linux drive on my machine, that I can boot into. In the next couple days, I'm going to try to find some time to shut down WinXP, boot into Linux, and run his app for a couple hours. I told him that I really couldn't run it with any seriousness, but I'd like to try it out. My girlfriend would probably have a very hard time working in Linux, and since she and I share this machine, I have to leave it running in XP.

I'll get some "results" up on the Software Comparisons page when I have them. He also gave me permission to post the source code, if anyone wants to see it. I'll have to figure out where it would fit in, or maybe I'll have to write a special page for his application.

Getting Mr. Gillies application made me think that I now have quite a few variations of a 196 program. I have John Walker's original, one from Jason Doucette, 4 different versions from Jack Ryan, 3 from Istvan, and now 2 from David Gillies. Maybe I need to start a "196 APPLICATION MUSEUM"...

I hope no one minds updating their bookmarks. (If anyone has any!!! :-O ) The geocities page is not going to be updated any more.

3/10/02 There are 2 iterations that contain a 29 Million digit number. The first one is 70,067,270.

3/8/02 8:26am Eastern Time, USA.

Iteration	Digit Count	Calculations Performed
69,513,622	28,771,338	999,999,957,083,118
69,513,623	28,771,339	1,000,000,006,225,600

More than 1 quadrillion calculations!!!!

3/7/02 Quite a few notes and comments tonight...

I got an email from Juergen Dankert in Germany. He was the one below that called me a "Computer Freak". He returned from a vacation, to find my message in his inbox. He replied with the following:

The official German dictionary ("the Duden") writes under the keyword "freak":
>"Somebody who feels enthusiastic about something very much."
>In this meaning it matches well anyway?
>However, I like to be ready write another expression for you to my web page ("Palindrome specialist", "196s guru", ...?)

>Best of luck four you, dear "Computer Freak".
>
>Your Juergen Dankert

Now, this made me laugh!! I would never call myself a "Palindrome Specialist!!! I guess one of the problems with languages, that I have never thought of before, is the fact that not everything translates exactly, from one language to another. It seems simple to me, that every word in one language would have an equivalent word in another. My limitation is that I am an American. I did not grow up learning anything other than English. Those of you from around the world that speak more than one language, have my admiration!! You are good people for taking the time to learn English. (How else could you read this site? :-) ) On top of that, I really do enjoy reading email from people around the world and knowing that it is not their primary language. Istvan, your English is VERY good. Some of the email I have received from others, has been a "challenge" to understand, but I really enjoy it!!!

Geocities Site Statistics tell me that there have been over 1,000 visitors to this site, and over 4,000 page views. I never imagined that there would be that many people visiting this site!!! I don't know if anyone has learned anything other than the fact that I am a "freak" ( :-) I think I'm going to remember Juergen's comments for a long time... :-) ) but it's nice to know that because of everyone's links, that this site is number 2 on a Google search of "palindrome +196". And the first link, is Patrick De Geest's site, mentioning this one. I wish I had more details about where in the world, everyone has come from. Maybe I'll start keeping a better list of visiting countries. Simply for my enjoyment...

I expect that sometime later tonight, I will cross 1,000,000,000,000,000 (1 quadrillion) calculations!! I've been watching it very closely, so I can try to determine a time for the crossing, but I don't have any way to "predict" when (iteration*digit)/2 will be 1 +15E. So I'm saving frequently, and trying to keep a close eye on it. I'd really like to be able to capture that time!!!

Speaking of time... Something I've been thinking about over the past month, and it ties in with the viewer stats, is a question to any of you as readers...

Are any of the pages, like this one, taking too long to load?

I was on a T-1 line at work, and am on a cable modem here at home, so I never notice page load times. They are VERY fast. but, would it be better for anyone, if I "archived" most of this page? Would it better if I broke up any of the other pages? This site is for you as readers. If it were just for me, I could just keep my notes locally on my hard drive, but I know there are people who check this site regularly, and I want it to be as easy for you as it can be!! If there is anything I can do to speed it up for you, let me know!!

Another thing... Since I am on a static IP address now, with the cable modem, and it is always on, I may move the site, and start serving it from my own machine. That would eliminate the Geocities ads that show up. Also, it might make it faster for those of you who are on other, fast connections. And there might not be any reason to worry about trying to make the site faster. If anyone has any ideas, (Jason?) I'd like to hear them. And of course... Any ideas for what would make a good domain name for this site?!?

I think that's it for tonight...

2/28/02 There are 2 iterations that have 28,000,000 digits. The first one is 67,648,377.

2/24/02 The 66,666,666th iteration is a number 27,593,723 digits long.

2/23/02 O.K., I'm back up and running. I got the parts from the store yesterday, and have the 196 application running on a P IV 1.9 GHz machine with 256m RAM. It's humming!! Last week, it was averaging 1.5823 iterations per second. Now, it's running at over 2.7998 per second. COOL!!! We should have some rapid progress. For a while...

2/21/02 I got thinking about the time palindrome below. Last night as I was waiting for it to occur here on the Eastern coast of the US, I started thinking that what is quoted below is wrong. There will be another Time / Date palindrome that is symmetrical. December 21, 2112, at 9:12 PM. Will be 21:12 21.12.2112. So there you go.

I have brought all of my stuff home from my old work, and now, I will be running the 196 problem from home. I ordered a Pentium IV 1.9 GHz board and chip. I'm just waiting for the store to call and tell me that it's arrived. Hopefully it'll be here in the next couple days!! I can't wait to get it working on this number!! Updates will show up as they happen.

A couple days ago, I saw a referring link to these pages that I hadn't seen before. So I followed it back to this page. Now, I can't read German, but I opened the page in a GOOGLE translation, so I could understand at least some of what they were saying. I have to laugh at the phrase "Computer Freak", that the person used to describe me and these pages. That doesn't seem fair... I guess it does seem crazy to do this, but I find it interesting enough, that I can live with being called a freak. I emailed the author of the page, but didn't hear back. I guess I'll just keep on being a "Computer Freak". :-)

2/13/02 A time Palindrome... As the clock ticks over from 8:01PM on Wednesday, February 20th, 2002, time will (for sixty seconds only) read in perfect symmetry. To be more precise: 20:02, 20/02, 2002. It is an event which has only ever happened once before, and is something which will never be repeated. The last occasion that time read in such a symmetrical pattern was long before the days of the digital watch (or the 24-hour clock): 10:01AM, on January 10, 1001. And because the clock only goes up to 23.59, it is something that will never happen again

I'm going to send this to Patrick De Geest, just for fun.

2/11/02 The 27 Million dataset finished last week, but I've been busy, and didn't have time to update this page. There were 4 iterations that contained a 27,000,000 digit number. Remember, you can see the Milestones and Data Set Information pages for details.

In the next couple weeks, I am going to be changing jobs. I intend to continue this search, but I won't have access to all the machines that I have now. I'll have to focus on one thing at a time, using the machines I have at home, which is an AMD 333Mhz and a 133Mhz. (Unless I can find something at the new company. :-O ) My girlfriend wants a new machine at home, so maybe I'll break down, and buy a 1.8 or something like that. I don't know. But, faster or slower, processing will continue, and these pages SHOULD continue to be updated!! Wish me luck...

1/30/02 Still no solution for the 196 changed digit testing. It's added 10.2 million iterations and 4.1 million digits, without forming a palindrome. I think I am going to turn it off. I want to use the machine for some other things. I'll save the file, and maybe continue on at another time. But, I don't see the "added value" by continuing any farther right now. I learned that it'll take far longer than I expected, so at least that's something. I can only assume that the 26 million file would take FAR, FAR longer to solve than the 1 million file. Maybe I'll change the LSB of the 1 million data set later and try it again.

The current run of 196, is supposed to finish 27 million on Feb 6. It is down to completing 1.6218 iterations per second, and adding 0.6716 digits to the total per second. It gets slower and slower...

I've got to find a faster machine!! :-)

1/28/02 The changed digit testing for 196 is over 8.5 million iterations added, and still has not solved into a palindrome.

1/24/02 The changed digit testing for 196 has reached 8,681,531 iterations and 3,593,280 digits. It still has not found a palindromic solution! This surprises me. It has gone through an additional 6,265,695 iterations and added 2,593,280 digits, since I changed the first number from a 1 to a 2. I'm thinking that it must be because the original number started with 1 million digits, that it's gonna solve eventually, but it will take a lot longer than I thought. Again, I think I wasn't taking into account the sheer size of the original number. Should I keep it running? I don't know. I think I will, until I want to use that machine for something else.

1/21/02 26 Million solved on Saturday. There are 4 iterations that have a 26,000,000 digit number.

On another note, I started testing changed save states, like I said below. I changed the first digit of the 1 million data set for 196 from a number 1 to a number 2 and started the program. It's now done a bit over 4.6 million iterations, and has added almost 2 million digits, but it has not formed a new palindrome. I'm not surprised at this, but on the other hand, this isn't what I would have expected. I figured it would take a while, but I don't think I expected it to take 5 million iterations!! I'm going to keep running it for another couple days, and see what happens.

01/17/02 I think the cause of the error last week was due to network problems. First, I must explain that I don't actually normally run the applications from local hard drives. I have them stored along with the data files, on a networked drive, so that I can access any of the files from any computer that I'm using. I've noticed this week, that the network has been going down A LOT. I have indeed had a couple of error messages this week, where the programs could not access the drive to save. I'm going to assume that what must have happened last week, was that in the middle of saving or reading the file, that the network connection got whacked, which in turn corrupted the data file. What I have done for right now, is located the data and program files on the independent local drives, so that this shouldn't be a problem again. I'm gonna continue like this for a little while, until I think the network is stable again. The responsibility for the network here where I work has coincidentally been shifted from one company to another, within the last two weeks, and I think they are doing some upgrades at the same time. I'm sure that it will stabilize out in the near future, and I can go back to doing things the "easy" way. :-)

Istvan asked me to play around with one of the saved files, and change a digit in the file, to see how fast it would migrate to a solved solution. Would it take a couple iterations and only a few seconds? Or would it take another 100,000 iterations and a couple days? We don't know. I am thinking that it should only take a relatively few number of iterations, to find a solution. The chances of stumbling upon a separate branch of numbers that has no solution, by changing one random number in the data file are even smaller than the odds of 196 solving out! And since the vast majority of numbers solve into palindromes in a very small number of iterations, I would expect that this would also solve fairly quickly. Even though I'm guessing that it will take several hundred or thousand iterations, simply because of the number of digits. But, I could be totally wrong!! This sounds like a very interesting idea, and I will most certainly try it out in the next couple days.

The other comment he made, was to maybe run "verification checks" on the existing data files, to ensure that they are still accurate. If I rerun the data file for say 19-20 million on a separate machine, and the result was the same, I could believe that there were no processing errors in the answer.

My thoughts here, are that I will play around with the files first, changing a bit here or there, first, last, middle, etc. Then, if the data shows that it will only take a small number of iterations to solve into a palindrome, then I can rerun the data for 25-26 and if it is correct, I will be able to safely assume that the ones prior to that are correct. This sounds like a very worth while thing to do!! If nothing else, it will make it easier to prove a result, if I do these checks at certain times, should I ever see that word "SOLVED" on my screen again.

01/15/02 You can imagine my excitement when I looked at the program Friday afternoon, (01/11/02 after I'd made the update for this page) and saw the following printed on the screen:

Solved
Initial value: 196
Iteration: 62255820
Number of digits: 25768054

I stood there for a second, and couldn't get a grasp on what I was seeing!! I went outside to get a cigarette, and to think for a moment. I came back inside, and opened the file. I still didn't believe that the file was correct. I looked at the first dozen digits, then went to look at the last dozen, to see if they were indeed the same. They were!! I started randomly picking out sections of the file, and searching for them in the end of the file. If the Most Significant Digits match the Least Significant Digits, then everything should be right in the middle right?!? Everything matched up. Five minutes after the last one, I needed another cigarette!! Imagine how excited I was!!

While I was smoking, I thought I should hold off on the grand announcement, and verify my findings. (I'd hate for someone else to find out I had made a mistake!!) I decided that I would use my latest backup, and would run it on all of the machines over the weekend, so that when I came into work on Monday, they would all say that it was solved, or they would say that there was an error.

I backed up the data files on three separate drives on the network, so that I wouldn't lose the answer. Then I found the latest backup that I had. I backup the file about every other day, so that if the program messes up, or the files get messed up, I only lose a few hours worth, not the entire million since the last save point. It turned out that I had a file from the morning of the 10th. So I stopped all other work that I had in progress, turned all of the machines on to 196, turned off the lights, and went home. Well, I came into work this morning, and with an excitement that I almost couldn't control, turned on the first of the five monitors...

Something had gone wrong last week. 196 had NOT solved out. :-(

All of the computers had moved up to iteration number 62,255,820, and moved on... You can see above, that the search still continues...

I was VERY disappointed!! This afternoon, still feeling let down, by the "failure", I opened the data file that had "solved" and started poking around inside it for a few minutes. You have to remember that this is a text file of over 25,000,000 digits, so when I am looking around in there, it's pretty hard to look at the whole thing in any logical manner. I started randomly bouncing around in the file. Just looking for anything that stood out. Then, right about the middle of the file, I saw it...

The other thing to think about in this text file, is that with THAT many digits, it LOOKS random. You can scroll the screen using "page down" for 3 minutes, and just watch the numbers scroll by, and it just looks like a bunch of numbers that have no meaning. (I've never had the patience to scroll on the line level. :-0 ) So when you see an entire dozen screens of 00000000000000000000000, it catches your attention!! Right there in the middle of the file, is a string of zeros. I didn't count them, but there are a bunch of them. (I'm going to guess that it's in the hundreds of thousands range) All of the digits before the zeros, match all of the digits after the zeros. (Except reversed of course.) I don't know what happened...

I've restarted again, back on the same machine, and am hoping to be able to duplicate the problem. But I doubt it will. I'll know tomorrow morning. I don't know what else to do.

So I've also restarted counting up, and maybe, just maybe, the next time, the program spits out a solved message, it really will be a valid solution!!!

01/02/02 I've been away from work for about 10 days, so I haven't updated the pages or numbers. I hope that everyone had a wonderful holiday period and a most happy New Year! I've got a couple updates I need to make, so I've been bouncing around the pages for a while, correcting this and that. Hopefully I got them all correct!

There are four iterations that result in a 25 million digit number. The first one is 60,398,130. I got to this number on Dec 28th. The total resulting calculation was 7.54977E+14. I think I may add the information for calculations for all the data sets, somewhere on the site, but I don't know where it would be appropriate. Maybe I'll create a "data" type page, similar to the Trivia page that I wrote. I'll have to think about it.

I also made some advances on 879, 1997, and 7059. You can still keep up with those numbers on the "Other Seed Numbers" page.

I got an email from Mr. Vincent Prosper in France. He and Sebastien Veigneau have papers that I've read which can be found here and here. He pointed out a couple things in my writings that are good and bad. He pointed out another error in John Walker's pages that I had missed. (Again, he wrote something I didn't question, but accepted.) In the section where John is talking about what a palindrome is, he makes the statement: In order for addition of a digits-reversed number to yield a palindrome, there must be no carries in the addition and hence each pair of digits must sum to 9 or less. I took this at face value, and have repeated the idea, based on it made sense, and if John Walker said so, it MUST be true!! :-(

Mr. Prosper points out the example of number 29. Hmmm...

Again, I have made a fairly large mistake. What I am happy about is that all of you are correcting me one piece at a time, and the site is becoming more and more accurate.

There was some other comments that Mr. Prosper made, that I have to think about a bit, before I fully understand them, but I'll write somewhere when I understand them. (Or If I can't figure it out, I'll write them, and someone else can HELP me understand them!!)

Again, HAPPY NEW YEAR TO ALL!!

196 AND OTHER LYCHREL NUMBERS

Random Quote

Site Links

Welcome to p196.org!