M64515779 has a factor: 6189543690695864260687 [TF:72:73:mfaktc 0.20 barrett76_mul32_gs]
M64515779 has a factor: 6273948586500036869753 [TF:72:73:mfaktc 0.20 barrett76_mul32_gs]
found 2 factors for M64515779 from 2^72 to 2^73 [mfaktc 0.20 barrett76_mul32_gs]

Not something I recall ever seeing. Bound to happen eventually I suppose

Nice! You won't see this, for the most of us, as we use the "when a factor is found, exit after current class". Your factors are from two different classes (1977 and respective 3964). So you have set the mfaktc to "when a factor is found, exit after current bitlevel", or not set to exit at all. Some people (me included) believe that is waste of time, in the most of the cases, after a factor is found, you don't need to "go higher". Some other people will blame me, and say that you can miss the smaller factor (not in your case, the smaller factor is in the smaller class) if you don't finish the bitlevel, etc.

Opinions vary, and finding factors is fun!

All in all, this duet of factors is very rare, a very nice find, congratulations.

I didn't know this was a thing. I suppose saving on average half the time on one exponent every time a factor is found isn't a huge deal but still.

I've gone and changed that. Neat feature.

[QUOTE=LaurV;359166]All in all, this duet of factors is very rare, a very nice find, congratulations.[/QUOTE]It's mostly rare because of the size of the factors (since as LaurV said it's common to stop immediately upon finding a factor), and that the two factors are in the same bit level. There's no shortage of exponents with multiple known factors, on my [URL="http://www.mersenne.ca/manyfactors.php"]Many Factors page[/URL] I don't list anything that has less than 4 known factors since there's far too many of them. But that's not grouped by size of factor, nor limited to factors in the same bit level. Running a quick database query on exponents below 10M I see 5959 (of 444942 = 1.3%) exponents have at least 2 known factors in the same bitlevel. Looking in the 50M range it's 3855/359501 = 1.1%

[QUOTE=TheMawn;359188]I suppose saving on average half the time on one exponent every time a factor is found isn't a huge deal[/QUOTE]
You are totally right here.

To make a bit of history talk, here people are split in two teams: some believe that is no reason to continue testing once a factor is found, and some other believe that letting the bitlevel unfinished is trouble, and not quite ethical... Well...in the future, our children will have faster hardware (and nothing better to do with it! :razz:) and will wish to continue to push the factoring limits higher, they may start with the next biltlevel and lose factors if they lay behind. Or some motivation like that. Because PrimeNet stores only the bitlevel which was done, it does not store the fact that such bitlevel was only "half done". Here again, we are victims of our imperfect tools: the right way should be to add the right field to the database.

In a word, finishing the bitlevel is not optimal for time, but is ethical, and it is what you pledged for, when you took the assignment.

Exiting after class is not ethical, it lets some work unfinished, but is "better" for the timing, assuming you do high bitlevels (to be clear: I am in this group of people, falling in the fallacy, see below).

Please remark the quotes of "better". Actually, here is where the argument came from, if you crunch at 70 bits, 5-6 minutes per exponent, you may find a factor every 70 assignments, which would take about 350 minutes, ~6 hours, so, every 6 hours you may lose 3 minutes (in average) to continue to check the rest of the bitlevel where you found the factor, and let the exponent "neat". If you TF at 75, and each exponent takes 5 hours, you may not like to lose 2.5-3 hours to finish a bitlevel, in spite of that on the long run, [U]the lost time is the same, or even lower, for higher TF levels[/U], i.e. you may find a factor every 75 assignments, which take 375 hours, from which you lose 2.5-3 hours to check the rest of the bitlevel.

So, theoretically, checking the whole bitlevel gets better as the bitlevel raises, because the factors are rarer there, and each time you find a factor, you "waste" in average half for the time per exponent per that bitlevel. The "fallacy" come from the fact that the "2-3 hours" are put together, seems to be a long time for "waste". At lower bitlevels you actually waste more time, but they are split in one minute here, one minute there...

As I said, opinions vary... You do your own [URL="http://en.wikipedia.org/wiki/Due_diligence"]due diligence[/URL] and set the parameters as you like.

[QUOTE=LaurV;359230]In a word, finishing the bitlevel is not optimal for time, but is ethical, and it is what you pledged for, when you took the assignment.[/QUOTE]

Thank you LaurV for phrasing it this way. An interesting interpretation and perspective.

I could very well be wrong (and would be happy to be corrected), but my understanding is it's a little more complicated than what you've outlined.

Based on something James told me quite some time ago when I sought his advise on how to fairly calculate "credits" (and which might have changed), Prime95 searches "upwards" when it TFs through a bit-level, while mfakt* searches downwards.

So it really comes down to those who want to know the lowest factor of all the MP candidates which have been factored cannot be sure they are all in the Primenet (and, separately, James') database for most of those candidates where a factor was found by mfakt*.

Some care; some don't.

Isn't it the case that mfaktc Factored results state "Partially tested," if 'StopAfterFactor=2'? Is this not carried over in PrimeNet reports on exponent status?

LaurV- Are you saying that only 'StopAfterFactor=0' is ethical?

On the other hand, by the time the hardware exists that people are trial factoring more or less for fun or to try to completely factor Mersenne numbers, they'll want to be double-checking the TF work to ensure nothing was missed in the first place. The likelihood of a factor being missed due to a GPU error is low, but for completeness they may want to TF every range twice to decrease the risk of anything being missed.


I too like the "What you promised to do" vs "What you set out to do" comparison. Quite subtle. Very interesting.

I'm trial factoring to cheaply eliminate candidates. As far as I am concerned, when I find a factor, I've eliminated that candidate and need not do any more work. If ever someone finds a serious flaw with this judgement, I'll be the first to switch back.

Of course, if someone did want to trial factor to higher limits for no better reason than finding as many factors as possible for known composites, they could just start over from the beginning of the bit level which contains the known factor. For the 1%-2% of exponents which DO have factors, re-doing the shortest bit level is really not a huge deal. If I found 2[SUP]70.01[/SUP] was a factor but it wasn't known if I factored all the way to 2[SUP]71[/SUP], redoing 2[SUP]70[/SUP] would be completely trivial in comparison to even 2[SUP]75[/SUP] (<2% of the total time [B]possibly[/B] wasted re-doing work on <2% of all exponents)

There's no "upwards or downwards" in currently implemented trial factoring in either of the programs. There are modulo classes that are turned into passes for efficiency. P95 and mfaktc have some differences in how these are used.

This misunderstanding probably stems from misreading George's remark in the code:
[CODE]/-- commonb.c around line 3950 --/

/* Set flag indicating a factor has been found! */

factor_found = TRUE;

/* We used to [B][COLOR="DarkRed"]continue factoring to find a smaller factor in a later pass[/COLOR][/B]. */
/* We'll continue to do this if the found factor is really small (less than */
/* 2^56) or if the user sets FindSmallestFactor in prime.ini. */

find_smaller_factor =
(end_bits <= (unsigned int) IniGetInt (INI_FILE, "FindSmallestFactor", 56));

/* Format and output a message */

makestr (facdata.asm_data->FACHSW,
facdata.asm_data->FACMSW,
facdata.asm_data->FACLSW, str);
sprintf (buf, "M%ld has a factor: %s\n", p, str);
OutputStr (thread_num, buf);
...[/CODE]
Well, this doesn't mean that P95 goes "downwards". It means that a smaller factor [I]may[/I] be found later in the remaining passes, in a different modulo class. [I]May[/I], not [I]will[/I].

And some (probably very few) people would like to know the smallest factor. Most won't care, only would care that this Mp is composite for the purposes of the project. Some would say that "it's not ethical to abandon the work that you signed up for; continue digging even though you already found water!", while others will retort, "No, I signed up to find water [u]or else[/u] until the end of the square plot. In this order. Instead of finishing digging this plot, I can do more use finding water on the next plot; well, or digging that next plot to its end if it will be barren."

[QUOTE=chalsall;359232]
So it really comes down to those who want to know the lowest factor of all the MP candidates which have been factored cannot be sure they are all in the Primenet (and, separately, James') database for most of those candidates where a factor was found by mfakt*.
[/QUOTE]
Just to pick nit: they can't do this anyways due to P-1 or ECM efforts.
E.g. I recently found a 94 bit factor for a M2,***,*** exponent (IIRC)(it's first known factor). It had been TF'd to 62 (again, running off memory). Who's to say there isn't a 62.1 bit factor for it?

[QUOTE=kladner;359237]LaurV- Are you saying that only 'StopAfterFactor=0' is ethical?[/QUOTE]
Not me! :smile:, remember, I am in the "fxuck the ethics!" team. :razz:
I just related the facts. There are advantages and disadvantages in both paths. You just chose yours.

Facts:

1. - GIMPS cares only about finding primes. There is where the glory and the money is. Once a factor is found (or a double LL is done), the exponent is scrapped. (don't argue with me here, the intention is not to argue with anyone).

2. - therefore once a factor is found, the factor is stored in the DB, and the "how far factored" is lost for the "public".

3. - other sites (mersenne.ca, etc) still keep the "how far factored", but some of them do not keep the "total" or "partial" for the last bit level, in case a factor was found there, and they do not keep the program used, the parameters (the number of classes), etc.

4. - some people care of finding factors more than finding primes, because finding factors is fun and easier to achieve, and factors may be useful for this or that math results, cryptography, whatever. Such people will continue to TF or P-1 mersenne numbers with known factors, higher and higher.

5. - once a factor is found, there is no way to know (beside doing your own recordings, homeworks, due diligence, etc) [B][U]how the factor was found[/U][/B]. This is important, because (as already pointed) different programs split the ranges differently (in bitlevels or in multiples of 60k candidates, etc) and for each range, do the sieving differently. Therefore, the guy who wants to "extend" the factorization, must [B][U]re-do the last bitlevel completely[/U][/B] i.e. to do [B][U]again[/U][/B] the work you already did. From this point of view, if you don't complete the range (bitlevel, or "up to 10^x, whatever you call it), is a bit unethical, like you asking/forcing the other guy to do part of the work you already did, to waste his resources to double part of your work.

To give you an example of calculus, assume one could use mfaktc to factor 2^71-1, with 420 classes. The factors are 228479, 48544121, and 212885833, but you don't know that yet. If you write them as 2*k*p+1, they are: 2*1609*71+1, 2*341860*71+1, 2*1499196*71+1.

Now, we have the modularity classes for k:

1609 = [B]349[/B] (mod 420)
341860 = [B]400 [/B](mod 420)
1499196 = [B]216 [/B](mod 420)

So, in this case, because mfaktc splits the range in classes, and it sieves and test the classes in increasing order, the biggest factor will be found first!!! Then the smallest factor will be found second, and only at the end mfaktc will find the middle factor (well, assuming we don't divide the other two factors out, which we can not do for high exponents).

If 4620 classes would be used ( bit too much for this exponent, bu we are talking here about exponents of millions), then

1609 = [B]1609 [/B](mod 4620)
341860 = [B]4600 [/B](mod 4620)
1499196 = [B]2316 [/B](mod 4620)

So the first factor is found first, then the biggest, then the middle one still found last.

If P95 is used, the factors will be found in order of the size: first, second, third.

If 2^191 is to be factored with mfakt*-like software, and considering we know the first (trivial) factor, depending of the number of classes, we can have either the third or the forth factor found first (here it makes more sense, as we still have a "cofactor" after dividing them out - think about exponents of millions.

[CODE]
gp > p=191; v=factorint(1<<p-1); print("\n"v[,1]); for(i=1,#v~,print(a=(v[i,1]-1)/(2*p)" : "a%4620" : "a%420" : "a%60))

[383, 7068569257, 39940132241, 332584516519201, 87274497124602996457]~
1 : 1 : 1 : 1
18504108 : 1008 : 168 : 48
104555320 : 100 : 100 : 40
870640095600 : 660 : 240 : 0
228467269959693708 : 3408 : 48 : 48
[/CODE]

Assuming that for some "exotic" exponent, there are 3 factors on the same testing range (bitlevel, etc), and the middle one in size is in the smallest class of k. That middle factor will be first found by mfakt* (which exits after the class), and stored in the DB.

If a guy wants to check for more factors, and he has no additional info (only the fact that the range was tested partially), then he [B][U]must recheck the last bitlevel, completely![/U][/B] Up, and down! Assuming he knows mfaktc was used, and he knows the number of classes, then he only need to check for the rest of the classes. Assuming he knows that P95 was used, he has to check all factor candidates bigger than the factor (due to the sieving style of p95). And so on.

(@chalsall: mfakt* does not test the candidates in "reversed" order, but in the incrementing order of the modularity classes, as in the example I just gave).

Of course, in the future the hardware will be more performant, and nitpickers will waste just few seconds to test our years-of-work, everything from scratch :razz:, but that is a different story.