[QUOTE=EdH;483657]They don't change permanently, hence the words "isn't persisitent." They do change status to "P" and the "Report factors" box goes away (at least for me), until you leave the page.[/QUOTE]
When you click "Factorize", you [I]jump[/I] from one number of the pair to another. The first number itself doesn't change status, it's just that you're seeing the other one.

I don't know which DB is used on the website, but that's not two "indices", it's just two rows in the database with different ID-s (that stands for [I]identity[/I]), the composite ones should be removed and everything's gonna be fine.

These are only two cases, booth easy to find.
Imagine there more, lets say at 127 digits.

[QUOTE=DukeBG;483673]When you click "Factorize", you [I]jump[/I] from one number of the pair to another. The first number itself doesn't change status, it's just that you're seeing the other one.[/QUOTE]I can see this now, but only after you've pointed it out and I search the links. The address changes from the id (which I mistakenly was referring to as index) to the formula version. But the formula version remains the one for the id I started with rather than the other (correct) one.

Original (faulty):
[code]
http://factordb.com/index.php?id=1100000000900935563

(10^79-181)%(10^79-1)/9
[/code]Original (faulty) after "Factorize!":
[code]
http://factordb.com/index.php?query=%2810%5E79-181%29%25%2810%5E79-1%29%2F9

(10^79-181)%(10^79-1)/9
[/code]Original (correct) one:
[code]
http://factordb.com/index.php?id=1100000000902314000

(10^79-181)/9
[/code]Correct one after "Factorize!":
[code]
http://factordb.com/index.php?query=%2810%5E79-181%29%2F9

(10^79-181)/9
[/code]I would expect that if the page is swapping to the correct page, it should reflect the page data for the other id. This does not appear to be the case.

[QUOTE=DukeBG;483673]I don't know which DB is used on the website, but that's not two "indices", it's just two rows in the database with different ID-s (that stands for [I]identity[/I]), the composite ones should be removed and everything's gonna be fine.[/QUOTE]I was referring to the ids as indices, but if an id is removed, might that leave a nuisance "hole" in the index?

Thanks for helping me learn more about the db.

[QUOTE=EdH;483692]I was referring to the ids as indices, but if an id is removed, might that leave a nuisance "hole" in the index?

Thanks for helping me learn more about the db.[/QUOTE]
No problem! Indeces are rebuilt automatically, deleting records is a pretty common task for databases :smile:

[QUOTE]Imagine there more, lets say at 127 digits.[/QUOTE]
Yeah, it would be more troublesome if much bigger numbers have multiple records in the database like this, I agree. I imagine SyD should be able to find them with a querry and eliminate. Pretty hard to find for us with what we can do, though.

I´m noticing many even numbers in the composite list.
FactorDB automaticly factors them with at least 2 as one-digit factor, sometimes they seem to be nearly FF. (Some of them have 60 and more digit factors.)

Not sure why, maybe search displays "old" data and updates them only when I quarry that specific number.

I´m now at 1399 digits and found 15 even numbers in a range from 100 random numbers with 1399 digits.

Anyway, these numbers passed the primality test and should have turned out as "n has a factor: 2" instead of composite.

(10420^1009-1)/10419 [url]http://factordb.com/index.php?id=1100000000491563582[/url] should be easy to prove prime by N-1, but factordb has been showing: [quote] This number is already in queue for N-1-test. [/quote] since yesterday.

I'd noticed it had nearly enough algebraic factors and started working on the remaining composites, ecm soon gave me enough factors.

Are any other numbers stuck waiting for a N-1 or N+1 proof?

Chris

grouporder incorrect
 

Recently, I have encountered the following problem.
There seems to be a bug in the grouporder calculation in the factordb backend.
Any ideas how I can independently compute the grouporder in Pari/GP or maple?

[COLOR=#000000][FONT=Helvetica]While running ECM on the number
120806075961504588321946561728616049181000544845508313914029203073449874696789043310743594833017812632630625045073648881
which is factor of (M127^10-1)/(M127-1) the surprisingly big (for this value of B1=[COLOR=#000000][FONT=Monaco]3E6[/FONT][/COLOR]) 53-digit factor was found, but factordb is rejecting the submission with:


Calculated grouporder [URL="http://factordb.com/index.php?id=1100000001117835996"][COLOR=#002099]9347845339...32[/COLOR][/URL]<53> is not within B1/B2 bounds (B1=3000000, B2=5706890290).[/FONT][/COLOR]
[COLOR=#000000][FONT=Helvetica]
[URL="http://factordb.com/index.php?id=1100000001117835996"][COLOR=#002099]9347845339...32[/COLOR][/URL]<53> = [URL="http://factordb.com/index.php?id=2"][COLOR=#000000]2^4[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=3"][COLOR=#000000]3^6[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=61"][COLOR=#000000]61[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=67"][COLOR=#000000]67[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=953"][COLOR=#000000]953[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=3457"][COLOR=#000000]3457[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=28387"][COLOR=#000000]28387[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=153533"][COLOR=#000000]153533[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=393697"][COLOR=#000000]393697[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=1457501"][COLOR=#000000]1457501[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=1948519"][COLOR=#000000]1948519[/COLOR][/URL] · [URL="http://factordb.com/index.php?id=122143467223"][COLOR=#000000]122143467223[/COLOR][/URL]<12>

PS: the factor is reproducible within ECM with:
[COLOR=#000000][FONT=Monaco]echo "(((2^127-1)^5+1)/2^127/6936637821829764980829848843805781)" | ecm -v -sigma 4121213133 3E6[/FONT][/COLOR]
...
[COLOR=#000000][FONT=Monaco]********** Factor found in step 2: 93478453399197362267241321867695840674203050027277001[/FONT][/COLOR]
[COLOR=#000000][FONT=Monaco]Found prime factor of 53 digits: 93478453399197362267241321867695840674203050027277001[/FONT][/COLOR]
[COLOR=#000000][FONT=Monaco]Prime cofactor ((((2^127-1)^5+1)/2^127/6936637821829764980829848843805781))/93478453399197362267241321867695840674203050027277001 has 67 digits[/FONT][/COLOR]


[/FONT][/COLOR]

What's your ECM version? I seem to recall some vague impressions of the ECM v7 group order stuff changing, with the FDB never catching up. (That, or something about the Brent-Suyama extension.)

grouporder incorrect
 

This is not specific to ECM v7, the same factor with the same sigma is found also by v6.4.3. Something must have changed, but nosing around in the source does not seem
to indicate any recent changes in how the elliptic curve is setup.

The grouporder on FDB is in agreement with the one found by the Magma script that someone gave me few years back:

FindGroupOrder2 := function (p, s)
K := GF(p);
v := K ! (4*s);
u := K ! (s^2-5);
x := u^3;
b := 4*x*v;
a := (v-u)^3*(3*u+v);
A := a/b-2;
x := x/v^3;
b := x^3 + A*x^2 + x;
E := EllipticCurve([0,b*A,0,b^2,0]);
return FactoredOrder(E);
end function;

p := 93478453399197362267241321867695840674203050027277001;
s := 4121213133;

(but there's a bug somewhere nonetheless, ECM cannot find factors with B2 bigger than the limit, and that is why factordb rejects such sigma, at the same time we know the factor is real, so the [B]only[/B] possibility is that the elliptic curve is setup differently in ECM than is assumed by factordb and the magma script )

[QUOTE=kosta;485712](but there's a bug somewhere nonetheless, ECM cannot find factors with B2 bigger than the limit, and that is why factordb rejects such sigma, at the same time we know the factor is real, so the [B]only[/B] possibility is that the elliptic curve is setup differently in ECM than is assumed by factordb and the magma script )[/QUOTE]

GMP-ECM can find factors when the largest prime in the group order is greater than B2, by virtue of the Brent-Suyama extension.

v7 also allows different curve parameterizations (README section 6). The readme says that the backward compatible -param 0 (Suyama parameterization) is the default, but I just checked and by default my 7.0.3 version uses parameterization "1".

None of this explains why factordb is having problems - I'm not sure what group order calculator it uses - but I think either could be possibilities.