12+ Table

[garo]

Size	Base	Index	Mod	Diff	Ratio
305	12	298	+	321.5	0.948
304	12	307	+	331.3	0.917
347	12	326	+	351.8	0.986
301	12	328	+	353.9	0.85
241	12	331	+	357.2	0.673
289	12	332	+	358.2	0.9
224	12	340	+	293.5	0.763	/5q
268	12	341	+	334.5	0.801	/11
302	12	344	+	371.2	0.81

[bdodson]

Originally Posted by garo

Base	Index	Size	11M(45digits)	43M(50digits)	110M(55digits)	260M(60digits)	Decimal
...
12	283+	C301	108(0.966149)	817(0.171654)	200(0.0270988)	0(0.00179541)
2899263343199310626741943807862276041815188882278492137895213600337560505804681086429980785818642360146503963148812824707494749803729717098940492182965910367332828804596058129162611858521759438516811806029868370244407570593202025903424097043967779816808498893160297152428186193285076403622186807890781
...

Must be the snow flurry that's lead to a factor flurry? Or that Pennsylvania
turnpike traffic jam, that seems to have made national and international
news (Japan, at least). Another early(!) xp factor; and the first in another
garo-list. Far from complete, though, c247 after

p55 = 1162855142932423233764354806486676128359791541463532749.
-Bruce

[bdodson]

Originally Posted by bdodson

.. Another early(!) xp factor; ... Far from complete, though, c247 after

p55 = 1162855142932423233764354806486676128359791541463532749.
-Bruce [February]

CWI has found another factor of this one,

12,283+ c247 = p53 * c194 CWI

p53 = 26125011969600077440822326298215406946517643673341327 [March].

Paul_Z asks whether someone could supply a p51 factor of the c194
for April? Lots of curves here, every day, 24 days and counting since
my last factor. Looks like I'll be able to finish t50 on the c3xx's that aren't
2- or 2+ for n < 1200; and also on c234-c250. Starting a run towards
t50 on the 2- or 2+'s in c251-c279 [38 of these] and a (short) run to finish
2*t50 on the last of the difficulty < 220 [reduced to the ones in c190-c250,
just thirteen of them]. That would leave just two t50 ranges to go,
2- and 2+ from c280-c366 and the generic c251-c299, both most likely
on the xps; along with more of a 2nd t50 on c190-c233, back to b1=260M,
on Opterons. I'm missing those "easy" p47-p52's. -Bruce

[bdodson]

Originally Posted by garo

Base	Index	Size	11M(45digits)	43M(50digits)	110M(55digits)	260M(60digits)	Decimal
...
12	244+	C190	0(2.27875)	805(0.430056)	1030(0.0732362)	0(0.00924638)
6365780983521780162885023026974257800936825074490073221517879479637604383978720583963786511055881283882617541341958188454834010481044790279603956191675076923029171984187037449158084171847513
...

Another table we haven't heard from for a while (one that's gotten a
LOT of focused attention from Peter/CWI). Found this one twice,

p51 = 452946673822467378677929191563830416376103729269433

to finish 12, 244+. Several points of interest here. While there hasn't
been any change in the grid scheduling software here (condor from
UWisc., Livny et. al), our hardware staff has been going through the
various public sites on this year's list, replacing old xp P4's with new
core2 duos at 2.4Ghz; even better, with 1Gb available to each virtual
machine, instead of 512Mb. In fact, now that I'm taking notice, this
may have had some effect on the recent successes with b1=110M on
c233-c250. The count of these has been going up for a while now,
and is scheduled to go up a bit more during August; 250 virtual machines
from 125 boxes.

Anyway, I plan on keeping the 512Mbs on b1=110M on c233-c250 for
a bit longer; but this is the first intentional core2 duo factor, with b1 =
260M! Found twice during the first 525 curves (1/3 of a t50). Not only
that, but a first factor for ATH's new 6.1.2 binary; this one at C190 using
the asm version, ... hmm ... Prescott, but perhaps I ought to have been
using Northwood? Anyway, the scheduling software makes two virtual
machines, so most likely the tasks I'm submitting go to a single core2
(and specific core2 dual improvements won't help). Sounds like a job for
Torbjorn, unless someone here is a core2 fan?

History here is that the p66 ecm record was with Torbjorn's AMD-64
binary (the p67 with PaulZ's); and Torbjorn's on record with the view
that xeons are best used for keeping rooms warm, rather than for
computing. Just checked the timings, the core2 timing is only 1/2 of
what those old Opterons are getting; which doesn't sound consistent
with intel's optimal performace advertisement. -bd

[wblipp]

Originally Posted by bdodson

p51 = 452946673822467378677929191563830416376103729269433

Found twice during the first 525 curves (1/3 of a t50).

Has anybody investigated whether some primes are intrinsically easier to find? That could be because there happen to be many more smooth numbers in p +/- sqrt(p).

William

[R.D. Silverman]

Originally Posted by wblipp

Has anybody investigated whether some primes are intrinsically easier to find? That could be because there happen to be many more smooth numbers in p +/- sqrt(p).

William

The Erdos-Kac Theorem is uniform in p, so except for "small number"
instances the answer is no. With a caveat.....

The interval is too short for current methods to yield a rigorous proof.
If you extend the interval to (say) [(1-epsilon)p, (1+epsilon)p] for
any epsilon > 0, then the answer to your question is no, asymptotically.
Primes will all have about the same number of smooth numbers in an
interval around them.

[bdodson]

Originally Posted by R.D. Silverman

The Erdos-Kac Theorem is uniform in p, so except for "small number"
instances the answer is no. With a caveat.....

The interval is too short for current methods to yield a rigorous proof.
If you extend the interval to (say) [(1-epsilon)p, (1+epsilon)p] for
any epsilon > 0, then the answer to your question is no, asymptotically.
Primes will all have about the same number of smooth numbers in an
interval around them.

Since I'm (by training) an algebraist, rather than an analyst (much less
analytic number theorist), I'm simply amazed when almost anything here
has a definitive proof, no GRH or anything. But the term "investigate"
doesn't necesarily force rigorous proof. Also, with Sato-Tate now
established, we could stretch somewhat closer to the endpoints of
the Hasse interval, maybe not p +/- 2*sqrt(p), but somewhat further
than sqrt(p), or better yet --- even with sqrt(p) --- the correct
weighting for the likelihood of values in p +/- (2*sqrt(p) - epsilon)
to occur as values of the order of an elliptic curve mod p. (That
circular measure, 1/sqrt(1-t^2), scaled for |t| < 1.)

On the subject of getting beginners interested in the relevant issues,
I'm always struck by how that middle part of the Hasse interval,
un-weighted, actually looks. Without taking a specifically computational
perspective --- really, really large numbers; but way, way off from
anywhere's near infinite --- it's hard to see much past 10-digits or
so. If one picks a random 30-digit prime, like

p30 = 573447428855263537365759829837

and notes sqrt(p30) = 757263117321359, one gets

[573447428855262780102642508478, 573447428855264294628877151196]

which takes some serious eye-strain just to see that there's anything
at all there, but still, the width is real nontrivial; that 2*sqrt(p),
15- or 16-digits. (What? The first ECMNET p30 isn't/wasn't random?)

The smallest p41, just above 10^40, gives width 10^20; and
this year's favorite large-factor size of p61 gives width above 10^30.
Black-swan issues aside, that's a really, really long interval; and one
doesn't get to push it out towards infinity, it has to stay there near
its p61-digit prime. So let's see, ... a whole bunch of p61's; so an
equally large number of intervals of width 10^30, but really not very
far out, near 10^60. In fact, if we were thinking specifically about
finding p30s, this is a finite problem (and considering p10000s then
p10000000s may not give the same problem, cf. the current status
of Birch-SwD data). My $0.02-worth. -bd

ps (on the sato-tate proof; that was the symmetric-square, needed
in Fermat and nontrivially entering into gl3, while s&t seem to have
observed (symmetric-square)^n --- or was that symmetric-n? ... was
the part of glN needed for the elliptic curve mod p distribution.
Given the elliptic curve, rather than abelian variety, the symmetric
square of the natural gl2; nth-symmetric power of natural gl2.
nevermind.)

[wblipp]

Originally Posted by bdodson

If one picks a random 30-digit prime, like

p30 = 573447428855263537365759829837

and notes sqrt(p30) = 757263117321359, one gets

[573447428855262780102642508478, 573447428855264294628877151196]

I wasn't able to figure out why Erdos-Kac was relevant. The connection between the number of factors and being smooth seems weak because it's easy to have many small factors leaving a large ultimate factor. But I decided the number of smooth factors was probably essential constant for reasons like the point you are making here.

The probability any one of these 2*757263117321359 numbers is smooth enough is going to be something on the order of 10^-3. An indicator variable for each will be a Bernoulli random variable with mean p and variance p(1-p), which is essentially p. The count of smooth numbers will be the sum of these indicator variables. If the indicator variables were independent, the mean and variance of the sum would both be about 10¹². It seems likely the indicators have slight negative correlation, but even if the correlation is positive, the variance can't get a lot larger. So a spread of "k" standard deviations on the count of smooth numbers looks like 10¹² +/- k 10⁶. The variation is much smaller than the error in the estimate of the mean.

[bdodson]

Originally Posted by wblipp

It seems likely the indicators have slight negative correlation, but even if the correlation is positive, the variance can't get a lot larger. So a spread of "k" standard deviations on the count of smooth numbers looks like 10¹² +/- k 10⁶. The variation is much smaller than the error in the estimate of the mean.

Another point, along a different line, if there were an interval of width
10^15 with significantly different distribution of smooth values, it
wouldn't affect the ecm probabilities just for a single p30; rather an
entire interval of them --- of course, there'd be lots of overlap for
nearby p30's, presumably all of them in an interval of width at least
10^10, or more. Lots of p30s; way lots. -bd

[Batalov]

12,259+ (diff.240) splits as p89 . p105.

Sieved on -a side only to a good excess by Bruce Dodson at lehigh.edu and finished with msieve (with a w<=40 tweak); the matrix was under 6M and took 56.5 hours to solve. Log is attached.

B+D

[bdodson]

Originally Posted by Batalov

12,259+ (diff.240) splits as p89 . p105.

Sieved on -a side only to a good excess by Bruce Dodson at lehigh.edu and finished with msieve (with a w<=40 tweak); the matrix was under 6M and took 56.5 hours to solve. Log is attached.

B+D

12, 253+ would not be an especially interesting snfs, but we did this
one by gnfs (not one of the marvelous firsts, or subsequent seconds).
Details are superseded by the c174 poly search by Serge, reflected
in the most recent update to 1.43. Another 3-4 days for 5p346; with
11p233 sieving. -Bruce

  prp74 factor: 83055775108512234821720209722177796088635498622860231287201890203396087471
  prp95 factor: 878699827110982728101200042516370725481333196918565571653036814461077209970954908826710711
05243 

Batalov+Dodson gnfs (!)