skipped bit levels

[LaurV]

Originally Posted by Madpoo

Yup, when you're done, PM me and I'll give you my email address to send your logs. I'll manually add those entries into Primenet so they'll show up in the history... no more wondering about the gaps since they'll officially be plugged.

Ok, this is what I have done. The first two I skipped, and later cancelled. My tool was too slow. I tried factor5 which actually is a bit faster due to the fact that is multi-threaded, but still too slow, so I don't like to keep my cores doing only this for weeks. Also, there may be some skipped or doubled assigned from Mark's list, because I spread the work to 4 GPUs each with 2 threads (copies of mfaktc) because 0.18 does not max the card and only does CPU sieving. Later, because one queue was faster then the other, I manually moved lines from one worktodo to other periodically, and added the results to the zip as they were done, also by hand. In all this process, assignments/results may be lost or lines duplicated. So please check again the DB if something missing. I won't mind to get some credit either

[Mark Rose]

I still have about 23 THzd to do, processing about 800 GHzd/d (the lower bit levels don't go so quickly). Looks like I should finish up in about a month.

Still only that one factor found about three weeks ago.

[dbaugh]

What happens to the exponent status history when a factor is found in a bit level that had been reported as no factor in that range by TF?

[Mark Rose]

Originally Posted by dbaugh

What happens to the exponent status history when a factor is found in a bit level that had been reported as no factor in that range by TF?

The factor is accepted, and the history remains.

[LaurV]

Originally Posted by LaurV

Ok, this is what I have done

@Madpoo: I checked some exponents today, the 58th bit is still missing, in the DB, so you didn't merge my last results in the DB yet... It is not about credit, but I am afraid that someone else in the future will see the missing bitlevels and he will waste the resources and time (for how many times?) again and again, to fill those holes. Probably many of them were filled already, but the info from the DB got lost, so I did them again. Please update the DB as per my post above, see the attachment.

[Mark Rose]

I should be done my efforts by the weekend. Still only that one factor found near the beginning.

[Madpoo]

Originally Posted by LaurV

@Madpoo: I checked some exponents today, the 58th bit is still missing, in the DB, so you didn't merge my last results in the DB yet... It is not about credit, but I am afraid that someone else in the future will see the missing bitlevels and he will waste the resources and time (for how many times?) again and again, to fill those holes. Probably many of them were filled already, but the info from the DB got lost, so I did them again. Please update the DB as per my post above, see the attachment.

As Mark notes below, he's going to be finishing soon and then I can take his and your output and do one import into the database.

[Madpoo]

Originally Posted by Mark Rose

Nothing between 64 and 65 bits, but I did just find this:

M35003827 has a factor: 14068547687256772529 [TF:61:64*:mfaktc 0.21 75bit_mul32_gs]

Which appears to be a skipped bit level.

By the way, when looking at M35003827 it does occur to me once more that "Never Odd or Even" shows up once again for another strange quirk.

Was it their own decision to skip ahead from 2^61 right up to 2^68 or did the server, for some reason, assign it that way (I don't see why it would have, but too late to tell now, except it doesn't look like those results were from assignments... i.e. they were done manually).

[Mark Rose]

Originally Posted by Madpoo

By the way, when looking at M35003827 it does occur to me once more that "Never Odd or Even" shows up once again for another strange quirk.

Was it their own decision to skip ahead from 2^61 right up to 2^68 or did the server, for some reason, assign it that way (I don't see why it would have, but too late to tell now, except it doesn't look like those results were from assignments... i.e. they were done manually).

In the end it was the only exponent with a missed factor, not counting any that were later found by P-1.

394,767 new no factor lines are now in your hands :)

[Madpoo]

Originally Posted by Mark Rose

In the end it was the only exponent with a missed factor, not counting any that were later found by P-1.

394,767 new no factor lines are now in your hands :)

And... importing those results now. First 200,000 of yours plus the stuff from LaurV have been imported.

e.g. M104309

The other ~ 200,000 from you will get added soon. Unsurprisingly it takes SQL a while to churn through that many inserts in a batch (I'm doing 100K at a time).

Just a note for you and LaurV, I haven't sussed out the formula for calculating the correct work credit on them. I could go back later and figure it out but for now I had to just use 0 GHz days on each entry...

I was actually just lamenting to AirSquirrels that I've never properly figured out where/how the server assigns credit for a result... I think it's in the PHP though and I'm importing these all into SQL directly so I would have had to recreate something. Well, maybe there's a little SQL function tucked away I haven't seen.

Anyway, I can look at that later.

[Mark Rose]

Awesome :)

I personally don't really care about the credit. It's about 45 THz-days or so from me over 7 weeks (very roughly 900 GHz-days/day with the lower bit levels).

Do let me know when the rest have been re-inserted. I'll download a new dump and double check to make sure I didn't miss any.

I may have to stop TF'ing indefinitely this spring/summer.