References: <941aad2c-bc3d-ca7a-1757-470e7ed1d5b9@free.fr>
            <87bmc3ripu.fsf@fencepost.gnu.org>
            <FAFAAEF8-5739-4255-8DB3-EFE2418830E4@wspr.io>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID:  <874lhvqn82.fsf@fencepost.gnu.org>
Date:         Fri, 22 Jun 2018 09:44:45 +0200
Reply-To:     Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender:       Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From:         David Kastrup <dak@GNU.ORG>
Subject: Re: Package registration
To:           LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <FAFAAEF8-5739-4255-8DB3-EFE2418830E4@wspr.io> (Will Robertson's
              message of "Fri, 22 Jun 2018 16:46:41 +0930")
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Will Robertson <will@WSPR.IO> writes:

> On 22 Jun 2018, at 5:54 am, David Kastrup <dak@gnu.org> wrote:
>> 
>> A stupid question that just occured to me: should we be discouraging
>> registering prefixes that match another prefix' contribution to the
>> overly simplistic hash function used in almost all TeX engines?
>
> Would it be easier to update the hash function in the engines? :)

Probably.

> What would be the easiest way to test for clashes?

Well, the hash function is just

@<Compute the hash code |h|@>=
h:=buffer[j];
for k:=j+1 to j+l-1 do
  begin h:=h+h+buffer[k];
  while h>=hash_prime do h:=h-hash_prime;
  end

So basically it's multiplying the ASCII codes by increasing powers of
two from right to left before reducing modulo hash_prime.  hash_prime
will tend to stay around for a few years until getting bumped but there
will be collisions even before the modulo operation.

Prefixes will tend to be less than 20 letters, so any programming
language offering 32bit integers should be fine for finding collisions
even before reducing modulo hash_prime.

-- 
David Kastrup