in reply to Stats for super search look buggy

My guess: the giant 2019 node ID jump from 1233781 to 11100000 influenced this. If it's calculating percentage of node number, assuming all nodes are populated, then that sounds about "right".

edit: (11132246 - 1220188) / 11132246 = 89.04% . Yep, no bug; just a feature of the giant node jump. /edit

Replies are listed 'Best First'.
Re^2: Stats for super search look buggy
by jdporter (Canon) on May 08, 2021 at 20:37 UTC

Great. Now I feel even worse about that. :-(

Well, the percentage calculator could be presumably changed to something like
```use constant jump => 9866219;
my \$delta = \$last_node_in_search_range - \$first_node_in_search_range;
\$delta -= jump if \$delta > jump;
my \$percent = 100 * \$delta / (\$most_recent_node_id - jump);

Right, but I don't think that the delta merely being larger than the gap is a sufficient test; we should check whether the search actually spans the gap:

```\$delta -= jump
if  \$first_node_in_search_range <= 1233781
&&   \$last_node_in_search_range >= 11100000;
I've already identified the code in question, but it's a little more complicated.

Furthermore there is also the "remaining" part, and the search could go backwards.

Interested pmdevs can submit patches here

``` 511:           . qq[ (searched ] . sprintf( "%.2f",
512:               100*( abs(\$n0-\$start)+1 ) / \$lastNode
513:             ) . qq[% of DB).</div><br />\n<div class="ss-criteri
+a-summary">\n];

and

``` 569:         } else {
570:             my( \$min, \$max )= \$oldFirst ? ( \$n0, \$lastNode ) : (
+ 1, \$n0 );
571:             my \$pct= sprintf "%.2f%%", 100*(\$max-\$min+1)/\$lastNo
+de;
572:             if(  1 == \$doSearch  ) {
573:                 \$html .= qq[Press ]
574:                   . \$q->submit( "nx", "Next >" )
575:                   . qq[ to <b>continue</b> searching remaining \$
+pct of DB.];
576:             } else {