Announcement: New server coming online (estimated 2017-08-11)

[GP2]

Originally Posted by S485122

Just an idea : '0E55078676173658' is a bit like an number in scientific notation (of course with only 0 before the E is does not make sense to have a number behind the E but nevertheless it might be interpreted as that type of value.

What's probably key here is that not only does it start with "0E" for pseudo-scientific notation, but the entire rest of the residue contains only decimal digits, with no hexadecimal A through F.

That probably explains the mystery. This is a rare combination. I see the following (as of August 1 2017 database):

Good (Verified)

6237239,Marc Getty / Phil Fizur,GLAD61,0E46733022873133,,1999-05-09 00:00
6237239,Hannu Kalli,sundqvist,0E46733022873133,,2001-08-18 00:00

11715481,Ars Technica Team Prime Rib,bayanne_clv3,0E82827430222472,,2002-05-05 00:00
11715481,Ars Technica Team Prime Rib,Reboot_It165,0E82827430222472,,2004-04-29 00:00
11715481,Brian J. Beesley,P4-2400B,0E82827430222472,,2004-07-26 00:00

17106697,Tom Mueller,ij,0E81997091872813,,2003-05-04 00:00
17106697,Bennett Atkinson,molokini,0E81997091872813,,2006-05-12 00:00

17537411,Nestor Abad,C72A38352,0E52489129574491,05000500,2003-02-02 00:00
17537411,John D Hagerson,ftptrain6,0E52489129574491,01000100,2006-10-24 00:00

33235339,Martin Lehmann,FRED,0E45102415700753,,2004-03-01 00:00
33235339,Patrik Johansson,kappa,0E45102415700753,,2011-08-21 20:59

37965407,doros,doros-xp,0E56229313676561,,2007-05-12 00:00
37965407,MadPoo,Manual testing,0E56229313676561,,2016-08-31 13:54

Bad

38620181,Evgeniy Smirnov,C2DBE3A02,0E45078840060154,00000100,2007-09-28 00:00

Unverified

41468027,Arie Yakobovich,250851,0E550786761736__,,2008-05-11 03:52
41814131,C. Cooper / S. Boone,grn129-18L,0E774144647932__,,2008-03-05 18:13
49671659,Der Arbeiter,hp,0E266321154917__,,2010-11-09 04:13
54501773,Amazon EC2,,0E338381245787__,,2012-01-29 07:28
55866757,Michael Hanscho,imbm-tmp,0E783225364937__,,2012-08-11 14:00
60168403,Metameer,JAP,0E326800927865__,,2013-04-21 00:53
60457513,LookAS,work4,0E898015946275__,,2015-10-02 12:30
69562891,rrranta,Desktop,0E212161526934__,,2016-10-21 09:21
70837421,arnaud,sgp-15-188,0E604298590503__,,2017-01-10 20:25

Maybe the unverified results in this list could be targeted for early double-checking? Although probably many of the unverified results have a hexadecimal digit in the hidden __ part.

And residues that start with E, with no leading 0, although again here many of these will have a hexadecimal digit in the __ part:

Good: none

Bad: none

Unverified

41287823,Stephan Grupp,sg107,E2072468416737__,,2009-04-11 01
44056853,-Anonymous-,chrispc,E6147813896242__,,2010-01-15 00
45518461,linded,v4_computers,E8341870790779__,,2009-03-13 09
45666323,benthomas,TermServe,E1992987924062__,,2011-03-20 09
46204519,cbwood,v4_computers,E3512007499065__,,2009-11-18 07
46782613,unconnected,new01,E7321685564617__,,2011-04-16 05
47268439,-Anonymous-,v4_computers,E7972527442283__,,2010-07-08 18
47458211,afj,pochta,E8024430311211__,,2012-09-05 12
47501749,Greg Hewgill,marble,E3983037005545__,,2010-10-31 21
47564017,akohler,ackhome,E5032774635451__,,2010-11-18 04
49548119,Jon Pace,Moms,E3075284745479__,,2011-04-13 09
49633951,mischa,mischa-desktop,E8487904104134__,,2012-02-18 17
49882601,WR,wr42,E7747104941964__,,2010-10-01 12
50079157,curtisc,wd-102--14l,E4300934401667__,,2011-07-01 15
50552609,CSLatDD,qaia39,E6973519159344__,,2010-07-06 04
51634481,curtisc,wd-102--13l,E5094037350485__,,2011-07-24 14
51868987,arnaud,srv-520,E1882994088280__,,2012-05-09 08
51886759,BobD,Mac2,E6333988092836__,,2012-10-29 11
52284929,Smok_bmv  ,bmv_cd_gen2,E4331216416048__,,2011-11-21 06
52423673,kagakubu,morilab_i3_2,E2532122060701__,,2012-07-14 19
52609489,linded,LKWXV7F,E9343149938868__,,2011-06-03 04
52957967,rogerioni,rogerioni,E0175386288221__,,2013-11-28 12
53228803,curtisc,grn122c-08l,E7341378744224__,,2012-07-17 12
53787137,Christian S,DOSe8,E0332219642223__,,2012-07-23 03
54042017,ANONYMOUS,Home_PC,E6112354962050__,,2013-08-14 18
54093647,Kimon Berlin,fckb2186,E2436582591870__,,2012-02-24 00
54831631,ANONYMOUS,,E2872205806976__,,2012-09-18 06
55582909,curtisc,wde2610-68l,E7881708748160__,,2013-04-17 02
55808381,troedel,,E7457778377429__,,2012-03-15 17
55895627,y52300,t1k4sVf9vKe5SoOf3,E1436879393368__,,2013-03-17 04
55970917,FT,2976,E1329332086371__,,2012-08-17 03
55995971,-Anonymous-,newbox,E0297058505543__,,2013-07-01 21
56028373,f1avalanche,Ferrari-Mac,E3468682314672__,,2012-01-23 23
56422673,curtisc,jckl-ccg24l,E6067134833725__,,2012-03-23 12
56805257,curtisc,wcm200--10l,E1573165613399__,,2014-01-19 13
58485799,curtisc,wde2610-35l,E1795094927260__,,2013-08-24 10
58494701,Darth Prime,Genesis,E1482345784011__,,2013-02-04 18
58618829,Son Johan,LaptopUltra,E6344530859176__,,2013-02-21 06
58969381,Amazon EC2,,E7673763246016__,,2013-07-20 15
59202629,curtisc,wde3107-18l,E4121510321370__,,2013-11-01 15
59951981,Chris,Rig,E1541478299944__,,2013-03-11 20
60011551,curtisc,csc142-01l,E4534386692502__,,2014-03-31 05
60053137,Farkas Istvan,x260,E1373490486225__,,2013-03-02 17
60959081,kamilste,R,E2789795039962__,,2014-05-29 06
62158553,curtisc,wcm229--21l,E0074163474629__,,2014-03-23 14
62476949,Dan Dugas,anthelio,E3513354598068__,,2014-02-20 08
63553603,rlake,wk1,E4096854138729__,,2013-12-21 23
63649909,jjnguy,work,E0971759030821__,,2013-11-09 02
65928211,bob5972,Elodin,E5930135459711__,,2015-02-11 07
67078763,UMNGopher07,UMNGopher07,E2840900324840__,,2015-06-13 23
68627777,curtisc,grn229--15l,E2269249933974__,,2016-07-03 02
69159733,curtisc,grn229--20l,E9726223270920__,,2016-05-06 02
69443953,DRH,DRH16,E9736437775256__,,2016-09-16 10
69490987,curtisc,grn209--10l,E4546582203367__,,2015-02-14 11
69534071,-Anonymous-,i74770_GTX770_GREECE,E4729111849711__,,2016-09-16 15
69711623,curtisc,wcm200--20l,E7064392776350__,,2016-06-26 10
70199671,Greg,Manual testing,E9322173986345__,,2016-08-26 21
70330739,-Anonymous-,,E9311832047192__,,2016-07-21 14
71624923,namja,DGL15,E2938513812498__,,2015-03-19 14
72285607,arnaud,sgp-15-152,E4648504652973__,,2017-05-16 21
72633907,curtisc,wde3100-22l,E6657918550060__,,2015-10-06 20
72866411,Michael Hanscho,smithicks,E9355756942057__,,2017-06-15 14
73104307,curtisc,grn016--10l,E3679741619125__,,2017-06-16 21
73267217,curtisc,wcm200--19l,E6098462634755__,,2017-02-08 16
73866061,curtisc,lov1130--15l,E2888572928646__,,2015-11-18 20
75152479,Chun sung soo,SERVER,E5063780020279__,,2016-01-22 09
75297121,Bahlouda,,E7614308774097__,,2016-06-04 01
75316903,George Woltman,KabyLake2,E6064632892245__,,2017-07-26 11
75860189,curtisc,wcm201--18l,E0205184435685__,,2015-10-03 20
77436803,Kuba Ober,,E7774922066103__,,2017-07-21 09
78338977,chaoz23,MS_Z820,E1763050070991__,,2017-02-17 13
78904799,John_P_Masseria,Dell2950,E0853007114296__,,2017-06-22 22
79577011,ari.orn,Proxima,E6864986670405__,,2017-01-31 13
81643607,super9mega,ray,E5118429542190__,,2017-06-05 18

[potonono]

http://php.net/manual/en/language.op...comparison.php

"If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value."


http://php.net/manual/en/language.types.float.php

"never trust floating number results to the last digit, and do not compare floating point numbers directly for equality."

[retina]

Originally Posted by GP2

... this mystery residue AF19BE28CD3746__ ...

Residue evaluates to 0 so therefore it gets a fake non-zero residue displayed to fool us unprivileged riff-raff.

ETA: I'd guess the last two digits are 50 or 05 completing the tour of all the hex digits.

[Madpoo]

Originally Posted by retina

Residue evaluates to 0 so therefore it gets a fake non-zero residue displayed to fool us unprivileged riff-raff.

ETA: I'd guess the last two digits are 50 or 05 completing the tour of all the hex digits.

Ding ding ding, you get the prize. (oh, and the final two digits of the phony residue don't actually exist, it's literally rendered with "__" but I guess it might have been "55" )

I put a failsafe in the exponent report that would only be triggered if all other methods of "hiding" new primes from being reported were to fail. It would display a phony residue (which I'll now have to change, LOL)

My code that looks for unverified primes in the history section was using the same "==" check for an all zero residue, which triggered on that same thing.

And yeah, the explanations of PHP treating it like a scientific notation float make total sense now that it's been pointed out there weren't any other A-F hexits after that "E" as the second character.

Talk about a rare circumstance... and it certainly explains why I couldn't trigger the same thing by testing out a few other values for a residue... it had to be of precisely that form. I guess something shorter like "0E1" would also equate to "000" in that same snippet of code.

[Madpoo]

Originally Posted by Madpoo

Talk about a rare circumstance... and it certainly explains why I couldn't trigger the same thing by testing out a few other values for a residue... it had to be of precisely that form. I guess something shorter like "0E1" would also equate to "000" in that same snippet of code.

I checked... there are 10 exponents where the residue matches this pattern (0E followed by only 0-9, no A-F)

8 of those exponents have been verified, so no problem. Only these 2 exponents match the pattern and remain unverified.
54501773
55866757

Both of those results came in 5+ years ago and the code change that prevented that recent check in was only added a month ago. The other issue was just my code to hide unverified primes in the history, so I guess anyone viewing those 2 exponents would have seen my phony residue.

That's also been fixed (and the phony residue changed).

In practice, that phony residue should actually never show up anywhere... there are other things in place to keep a new/unannounced prime from appearing in results or whatever, so now I really hope that particular code never gets run. LOL

The other already verified exponents that match that pattern, in case anyone wants it for a trivia question:
6237239
11715481
17106697
17537411
33235339
37965407
38620181 *
41468027

(* - M38620181 actually only has that residue on a bad result - and oh fun, I did the verifying check)

[chalsall]

Just to give some feedback... All the spiders / scripts I have running appear to be working nominal. And, noticeably quicker! Thanks Aaron!

[GP2]

There are a few cases with two leading zeros (and none with more than two):

Good (verified):

23747261,Megan Vaughn,culex,00E5286089746753,,2004-04-20 00:00
23747261,-Anonymous-,SrvrUID,00E5286089746753,,2010-09-13 20:05

Unverified:

52086613,unconnected,uae-5,00E81080330073__,,2011-11-08 13:49
53791711,rick,sophia,00E09749063994__,,2013-03-13 19:19
58133261,Corran,rrint10,00E62684668690__,,2012-06-07 22:47

Here again, the hidden __ might contain hex digits.

[Madpoo]

Originally Posted by GP2

There are a few cases with two leading zeros (and none with more than two)
...
Here again, the hidden __ might contain hex digits.

Here are only 2 (the others must have had A-F in the masked portion, I didn't verify but must be the case):
23747261
58133261

And yup, none with "000E" ... there are only a handful that even start out that way... 5 verified and 9 unverified.

Just one exponent starts with "0000E" and it's verified: M26508367

Nothing beyond that... pretty rare to get a string of any 5 hexits in a row anyway. It happens, but just 341 of those...

Here's a fun bit of stats then... for explanation, I'm excluding bad results since those sometimes have a bunch of zeros or Fs in a row. I also excluded any that start with 8 zeroes in a row. Some old code only turned in partial residues below 64 bits (they've all been verified using matching 64-bit residues since then).

3 in a row: 85381 exponents
4 in a row: 4992
5 in a row: 319
6 in a row: 17
7 in a row: 3

Each of those counts includes exponents with more than the listed # of digits in a row... e.g. the "6 in a row" includes the 3 that have 7 in a row

Those 3 exponents with 7+ in a row are:
435763
731767
801883

The weird 7 zeroes in a row must be due to that strange little bug with certain shift-count sizes. 2 of them are my results.

The exponents with 6 hexits in a row that aren't the result of some weird glitch are:
2967247
4878943
6332317
10268009
13949603
17038523
21642389
37893607
42863333
52900531
72238961
72928847
73995527

Those last 4 are unverified... could be correct, but maybe not. Enjoy.

[Madpoo]

Originally Posted by Madpoo

... I'll resubmit that result for you. That should take care of it now and in the future.

LOL...

User "monst" got a LL credit bonus courtesy of yours truly. I checked in a few results today and forgot I was logged in as him after resubmitting that result after the fix.

Well, enjoy, and let's just say the extra CPU credit is your reward for being patient as I figured it out and also for helping find a new bug and letting me know.

[Madpoo]

FWIW, I used the old server to do a few tests with things.

First one was upgrading from SQL 2012 to SQL 2016. Worked fine... we weren't using any deprecated things as far as I saw beforehand, and as expected it worked just fine after.

The other big change I tried was upgrading PHP 5.x to PHP 7.1. Couple big things with that were that they finally have a good 64-bit PHP version for Windows, and 2nd, with PHP 7.x 64-bit, integers are finally treated the same as on Linux 64-bit, meaning you can use real 64-bit signed INT.

The reason that's cool is because that was a problem if we ever wanted to expand Primenet to handle/track exponents above 2^31. Now it could handle 2^63 without having to resort to some PHP hackery.

SQL would still need to change some columns to bigint from int but all in all, technically possible.

The SQL upgrade is higher on my to-do list for the live server. Reason being, the new server has more memory available, but SQL 2012 Standard has a hard limit of 64GB for (most) memory usage. SQL 2016 Standard bumps that to 128GB which would give us some nice headroom.

And yes... all that Primenet data does use quite a bit of RAM. Not so much the data itself, but the indexes on the data to help with all those queries do take up a huge chunk. At least as much, if not more, than the data itself.

I know some of y'all are just hoping I'd do some other updates, even relatively minor like switching to nvarchar for a few things (user/cpu names)... I'll get there in time.

[aurashift]

neato