Possible spammers joining Einstein

Inquiries reveal that these sign ups are from Grid Republic ie. legitimate users, perhaps the numbering used to generate usernames is some anonymity mechanism they use.

Cheers, Mike.

I had a fiddle with that, and to me it looks like some sort of 'balancing' of load/index technique ie. sprinkling entries across pigeonholes. If you try ( my red emphasis )

http://einstein.phys.uwm.edu/user_search.php?search_string=ceX&search_type=name_prefix&country=International&profile=no&team=no&action=Search

for different single integer decimal digits where the 'X' is then :

- it has no entries for 0,1,7,8 or 9

- for 2 it is in the range 2848 thru 2999

- for 3 it is in the range 3000 thru ~3200

- for 4 thru 6 they are roughly in the range X000 thru X099

Giving the impression of a round robin allocation with sequential loading of each 'bin'. Possibly with a change of strategy/technique/algorithm at some point. But who can say ?? :-)

Cheers, Mike.

( edit ) I'm aware that file systems generally don't "want" either too much breadth or depth or excessive entries per directory ( all terms relative here ). Git - a content based code repository manager - does a hash on each object it deals with giving a rather long hexadecimal string. It takes the first two hex digits of that and then names sub-directories by them, so the directory that contains them will have at most 256 sub-directories of that type. Hence all objects with a hash beginning with 'a6', say, will be kept in the same sub-directory called 'a6'. The remaining hash digits for each distinct object then make up the filename to store the actual content within. Given that SHA-1 hash values jump all over the place even with minor changes to the object it is generated from then there is a good chance of an even spread of load.