Primenet web design

[swl551]

Please consider...

F.Y.I. The leaderboard will have to be fixed to work with the new GIMPS pages


MISFIT can no longer parse http://www.mersenne.org/report_top_500/

I'll shoot for a MISFIT patch by the weekend.

What would really be cool is a version of the stats page that returned XML so I don't have to screen scrape then convert to XML on my side.

It sure would make building a GIMPS leaderboard phone app easier. (not that anyone is asking for such a thing)

<?xml version="1.0" standalone="yes"?>
<NewDataSet>
  <xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
    <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:MainDataTable="StatsTable" msdata:UseCurrentLocale="true">
      <xs:complexType>
        <xs:choice minOccurs="0" maxOccurs="unbounded">
          <xs:element name="StatsTable">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="id" msdata:ReadOnly="true" msdata:AutoIncrement="true" type="xs:int" />
                <xs:element name="rank" msdata:ReadOnly="true" msdata:Caption="Rank" type="xs:int" minOccurs="0" />
                <xs:element name="person" msdata:Caption="Person" type="xs:string" minOccurs="0" />
                <xs:element name="credit" msdata:Caption="Ghz Days Credit" type="xs:double" minOccurs="0" />
              </xs:sequence>
            </xs:complexType>
          </xs:element>
        </xs:choice>
      </xs:complexType>
      <xs:unique name="Constraint1" msdata:PrimaryKey="true">
        <xs:selector xpath=".//StatsTable" />
        <xs:field xpath="id" />
      </xs:unique>
    </xs:element>
  </xs:schema>
  <StatsTable>
    <id>0</id>
    <rank>1</rank>
    <person>THEJUDGER</person>
   <credit>1204413.201</credit>
  </StatsTable>
  <StatsTable>
    <id>1</id>
    <rank>2</rank>
    <person>NEVER ODD OR EVEN</person>
    <credit>906154.351</credit>
  </StatsTable>

[tha]

The 'Most recent cleared' list has two vertical scroll bars. One of them is not used. It would be less confusing/more esthetic if a scroll bar is either used or not displayed.

[S485122]

Originally Posted by tha

The 'Most recent cleared' list has two vertical scroll bars. One of them is not used. It would be less confusing/more esthetic if a scroll bar is either used or not displayed.

In my opinion for the horizintal scroll bar at the bottom to be usefull, the screen should be smaller and only the inner vertical scroll bar would be used (and dispales.)

In that same report some hiccups do appear :

TheJudger            Manual testing   68642207  F-PM1    Oct 12 2014  4:39PM   0.0   2.5551  21445402905229038631109113
TheJudger            Manual testing   70598147  F-PM1    Oct 12 2014  4:39PM   0.0   5.4743  1566412351258828452690480338649165988814871246977
TheJudger            Manual testing   70598147  F-PM1    Oct 12 2014  4:39PM   0.0   5.4743  1566412351258828452690480338649165988814871246977
TheJudger            Manual testing   78992827  F-PM1    Oct 12 2014  4:39PM   0.0   8.1747  3277351443012856336789601
TheJudger            Manual testing   78951793  F-PM1    Oct 12 2014  4:39PM   0.0   3.8866  8632004845949323282833271
TheJudger            Manual testing   70234819  F-PM1    Oct 12 2014  4:39PM   0.0   2.8004  3862142044227688474819567
TheJudger            Manual testing   78991153  F-PM1    Oct 12 2014  4:39PM   0.0   8.1747  39391963745149259402173826729
TheJudger            Manual testing   72855707  F-PM1    Oct 12 2014  4:39PM   0.0   2.7186  2004965467152274683237527
TheJudger            Manual testing   78548549  F-PM1    Oct 12 2014  4:39PM   0.0   3.8866  5420344603509705124758577
TheJudger            Manual testing   72855689  F-PM1    Oct 12 2014  4:39PM   0.0   2.7186  88180296313195560474857
TheJudger            Manual testing   78548467  F-PM1    Oct 12 2014  4:39PM   0.0   3.8866  56722614925121005645839419906553845091822499901725481423
TheJudger            Manual testing   78548467  F-PM1    Oct 12 2014  4:39PM   0.0   3.8866  56722614925121005645839419906553845091822499901725481423
TheJudger            Manual testing   74506343  F-PM1    Oct 12 2014  4:39PM   0.0   6.5690  34261612362761935957478977
TheJudger            Manual testing   78548417  F-PM1    Oct 12 2014  4:39PM   0.0   8.1747  3102699374115027381906979512991
TheJudger            Manual testing   70612307  F-PM1    Oct 12 2014  4:39PM   0.0   5.4743  477421324208926378840703
TheJudger            Manual testing   70218359  F-PM1    Oct 12 2014  4:39PM   0.0   2.8004  71445594648112827221596505052906998133757634209
TheJudger            Manual testing   70218359  F-PM1    Oct 12 2014  4:39PM   0.0   2.8004  71445594648112827221596505052906998133757634209
TheJudger            Manual testing   78548329  F-PM1    Oct 12 2014  4:39PM   0.0   3.8866  108786830247367218130687
TheJudger            Manual testing   70612279  F-PM1    Oct 12 2014  4:39PM   0.0   5.4743  62057717201199210463273039

Notice the beautifully huge factors (you will have to scroll horizontally) ? They must be so beautiful that they are there twice :-)

Jacob

[James Heinrich]

Originally Posted by S485122

Notice the beautifully huge factors (you will have to scroll horizontally) ? They must be so beautiful that they are there twice :-)

It was reported as a composite factor and recorded as two separate smaller prime factors. I'm not familiar with the inner workings of the recent-cleared report so I'm not sure why it's reporting the two recorded factors as the composite factor rather than each of the prime factors. It is recorded correctly in the database.

[snme2pm1]

PrimeNet Most Recent Results, http://www.mersenne.org/report_recent_results/
and
PrimeNet Most Recently Cleared Not-Prime, http://www.mersenne.org/report_recent_cleared/
both sport non-standard date/times.
Since often the date is the same or different by only one, space could be saved by removing the date part entirely.
The time part of those reports is yet to be made 24 hour format.

Known primes, http://www.mersenne.org/primes/ still has non-standard dates.

Not to mention some other places of editorial style content with long US style dates.

[Madpoo]

Originally Posted by tha

The 'Most recent cleared' list has two vertical scroll bars. One of them is not used. It would be less confusing/more esthetic if a scroll bar is either used or not displayed.

*Most* of the time those results won't need a horizontal scroll, but if there is a large factor-found result, then it would need to scroll.

There's something weird where turning on the "overflow:scroll" setting causes those scrollbars to show up no matter what. Maybe there is a way to have those only show up if needed and I'm just dense enough to have missed that. :)

[Madpoo]

Originally Posted by snme2pm1

PrimeNet Most Recent Results, http://www.mersenne.org/report_recent_results/
and
PrimeNet Most Recently Cleared Not-Prime, http://www.mersenne.org/report_recent_cleared/
both sport non-standard date/times.
Since often the date is the same or different by only one, space could be saved by removing the date part entirely.
The time part of those reports is yet to be made 24 hour format.

Known primes, http://www.mersenne.org/primes/ still has non-standard dates.

Not to mention some other places of editorial style content with long US style dates.

Yeah, those reports still come out of SQL and I haven't monkeyed with the queries themselves unless I absolutely had to for some reason.

Changing the date format on those should just be a matter of changing the query to convert the stored datetime to the correct format. The places where dates are manually added tend to be the press releases which tend to have a more formal date... I've run across a few and besides making the date itself bold or something on the home page so it stands out, I didn't think changing them to use yyyy-mm-dd would have made it better... the releases or news items are already listed in chrono order on the home page which should do.

A question there is, would this break any scraping scripts people have? There *probably* aren't any scripts grabbing data from those reports because they're non-inclusive... they only run once an hour and show the last XX. It's probably safe to change that, but fair warning...

Same thing applies to the different number formats. Different countries use commas or periods for thousands separators, and in some reports it'll use commas, or spaces, or no separator at all. That last is especially true of factors... the factors tend to be so large, adding any separator is pretty pointless. They're too large to store in a database as anything but text. Adding dots/commas/spaces in there would be no fun. :)

Having thousands sep on the factors makes them more readable at a glance, I think. If I were to pick a single one to use, I'd go with thousands=comma and decimal=period. It's a US project, US website, but at the same time I recognize the big international contributions. Fortunately I think countries where a period is the thousands separator are used to seeing it writ the other way around.

For now I'll let that sleeping dog lie, because it seems like one way or another, someone wouldn't like whatever it does. LOL

We could present the data in a raw number and use Javascript to render it in your browser's locale but that seems like overhead it could do without.

[Madpoo]

Originally Posted by James Heinrich

It was reported as a composite factor and recorded as two separate smaller prime factors. I'm not familiar with the inner workings of the recent-cleared report so I'm not sure why it's reporting the two recorded factors as the composite factor rather than each of the prime factors. It is recorded correctly in the database.

There's an hourly process running that pulls that data from a view. I haven't looked at that view itself to see what it's pulling together, or what else uses that same view.

A quick glance at the view right now shows 4 entries where the same result appears twice, and it doesn't have any more info in there as to why. Looking at one example in particular, a factor for 70598147 was found using ECM by a user, and it's recorded twice in the results table, about 400 milliseconds apart. Not sure why.

It's the same story for the other 3 duplicates I see currently... they were submitted twice, 300-400 ms apart.

[James Heinrich]

Originally Posted by Madpoo

a factor...was found using ECM by a user, and it's recorded twice in the results table, about 400 milliseconds apart. Not sure why.

The manual results form would check for compositeness of the submitted factor, and the results should be handled for each of the prime components of the submitted factor. The 400ms offset between submissions makes perfect sense from processing one factor to the next. As far as I can see from the manual results code it should only be the prime factor passed to the database. If I had to guess (wild speculation), perhaps the full submitted result line (which would contain the composite factor) is being parsed into the report rather than using the actual factor from the database.

[Madpoo]

Originally Posted by James Heinrich

The manual results form would check for compositeness of the submitted factor, and the results should be handled for each of the prime components of the submitted factor. The 400ms offset between submissions makes perfect sense from processing one factor to the next. As far as I can see from the manual results code it should only be the prime factor passed to the database. If I had to guess (wild speculation), perhaps the full submitted result line (which would contain the composite factor) is being parsed into the report rather than using the actual factor from the database.

I think in this case, it might have been the specific user with their manual results pasted in. 3 of those 4 anyway (I didn't look too much closer) were from the same user in the same 3-4 second time period, so I wonder if it was just duplicate lines in the results being pasted in. The raw results log shows the same entries submitted twice.

[Madpoo]

Originally Posted by Madpoo

*Most* of the time those results won't need a horizontal scroll, but if there is a large factor-found result, then it would need to scroll.

There's something weird where turning on the "overflow:scroll" setting causes those scrollbars to show up no matter what. Maybe there is a way to have those only show up if needed and I'm just dense enough to have missed that. :)

I'm apparently not good at reading the full CSS documentation. "overflow:auto" would do what I intended... ONLY show the scroll bars *if* content needs it.

I'll go through all the places I added that and switch it to auto which should look better. I updated that recent cleared report already and it's good.

FYI, I forgot I hadn't switched those recent results/recent cleared to use the table format yet instead of that pre-formatted text output. Working on that now. It's just a nicer presentation and can give some sorting options other than the default "date".