Odd factor-with-no-factor result noted on [url=http://www.mersenne.org/M48585853]M48585853[/url] (also [URL="http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48585853"]xml[/URL])

edit: there's a bunch of them... found so far:
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48585853]48585853[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48808681]48808681[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48813043]48813043[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48819677]48819677[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48824753]48824753[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48881629]48881629[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48917471]48917471[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48964859]48964859[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49050139]49050139[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49167337]49167337[/url]

Not all the same user, but all in the same range, presumably a server error of some kind when those results were submitted?


PS: this one has a malformed NF result:
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49305689]49305689[/url]

[QUOTE=James Heinrich;399825]Odd factor-with-no-factor result noted on [url=http://www.mersenne.org/M48585853]M48585853[/url] (also [URL="http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48585853"]xml[/URL])

edit: there's a bunch of them... found so far:
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48585853]48585853[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48808681]48808681[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48813043]48813043[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48819677]48819677[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48824753]48824753[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48881629]48881629[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48917471]48917471[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=48964859]48964859[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49050139]49050139[/url]
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49167337]49167337[/url]

Not all the same user, but all in the same range, presumably a server error of some kind when those results were submitted?[/QUOTE]

Just checked the data:[LIST][*]241 entries for factor found by P-1 and missing the actual text from the client[*]81 entries for factor found by ECM but missing the client text[*]18 entries for NO factor found by TF but missing the client text[/LIST]
The actual factor found was still recorded, it's just missing the actual text from the client showing the client info, factor, how far factored, etc.

The dates of those entries are generally in a narrow time period from Nov 10, 2008 to Nov 30, 2008 with a few outliers from late October 2008.

Nothing too common with all of them except they all appear to come from the manual results page.

Would anyone care for a list of those exponents and what method was used to find the factor (tf/p-1/ecm) ? Or is knowing the factor itself is peachy?

[QUOTE=James Heinrich;399825]PS: this one has a malformed NF result:
[url=http://www.mersenne.org/report_exponent/default.xml.php?exp_lo=49305689]49305689[/url][/QUOTE]

The recorded text from the client on that one is simply:
" [UNASSIGNED]"

Must have been something going on with the text parser at the time. That one was from the same time frame as the others, Oct 27, 2008.

[QUOTE=Madpoo;399828]...it's just missing the actual text from the client showing the client info, factor, how far factored, etc.[/QUOTE]If you're able to, can you twiddle the database to replace all the invalid "Factor: <nothing>" reports with "Factor: <factor>". The XML report at least already shows the user/date/method, just missing the actual factor:[code]<result dateReceived="2008-11-24 21:04" userName="TMarshall" resultType="F" resultText="factored by trial factoring">
<resultMessage>Factor: </resultMessage>
</result>[/code]

Another type of not-useful result for [url=http://www.mersenne.org/M58182017]M58182017[/url] ([url=www.mersenne.org/report_exponent/default.xml.php?exp_lo=58182017]xml[/url]).
Note the "no factor" result that doesn't say no factor between what and what bitlevels, just "no factor".

Same on: 58634963, 58182017, 58866581
Variant "no factor [UNASS" on 58155389, 59223029

No factors?!?! It must be prime then!!!1

Some exponents have factors displayed incorrectly:

e.g. [url]http://www.mersenne.org/M66362159:[/url][code]result: M66362159 has a factor 124246422648815633
display: Factor: 159[/code]

Also noticed on [url=http://www.mersenne.org/M66001631]M66001631[/url] and [url=http://www.mersenne.org/M66000007]M66000007[/url].

[QUOTE=James Heinrich;399852]Another type of not-useful result for [url=http://www.mersenne.org/M58182017]M58182017[/url] ([url=www.mersenne.org/report_exponent/default.xml.php?exp_lo=58182017]xml[/url]).
Note the "no factor" result that doesn't say no factor between what and what bitlevels, just "no factor".

Same on: 58634963, 58182017, 58866581
Variant "no factor [UNASS" on 58155389, 59223029[/QUOTE]

Yeah, those are all in that same timeframe of late October/early November 2008.

The result text as recorded in the DB is either blank or contains "[UNASSIGNED]" of all things.

Between you and George, do you think it would be easier to "fix" the weird DB entries, or change the "pretty" parsing to handle cases like that better?

For my money it's probably easier to correct the DB entries and try to fill it in with the basics of what the client probably had in there, although that won't always be the case.

Where it's a "no factor found" type of result, there's no way to know what the client sent in terms of "from bit X to bit Y", just that it didn't find any factor. I wonder if that log entry is meaningful at all in those cases and what to do about that.

For the ones where a factor was recorded but that log text is missing, we could at least "fill in" the info the client *should* have included, like the user/cpu info, the actual factor for whatever exponent, perhaps the app string. But to keep it simple maybe just the bare minimum to have it parse correctly.

Something's up with Primenet. Spidy's been reporting errors since 2235.

[CODE]20150411_223501 INFO: Get Manual Work spider starting...
20150411_223521 ERR : Bad response: 500 read timeout[/CODE]

Anything wrong with mersenne.org?
I can´t get to the site, although I´m able to access any other site at will.

(Seems like chalsall has beaten me to it...)

[QUOTE=Madpoo;399876]

The result text as recorded in the DB is either blank or contains "[UNASSIGNED]" of all things.

Between you and George, do you think it would be easier to "fix" the weird DB entries, or change the "pretty" parsing to handle cases like that better?[/QUOTE]

You could delete the meaningless DB entry. That would make the result just like all results up to November 2008 -- the result text was not recorded.