From: notsaying@nospicedham.invalid.org   
      
   On Sun, 11 Nov 2018 13:14:13 GMT, Rod Pemberton   
    wrote:   
      
   > On Sun, 11 Nov 2018 11:07:19 -0000 (UTC)   
   > "Kerr-Mudd,John"  wrote:   
   >   
   >> On Sun, 11 Nov 2018 05:37:00 GMT, Rod Pemberton   
   >>  wrote:   
   >   
   >> > I tested about 50 hash functions with brute-force text input about a   
   >> > decade ago (comp.lang.misc):   
   >> >   
   >>   
   >> Thanks for that; I'm not looking to have uniqueness over the entire   
   >> ASCII (or even all Cap letters combinations);   
   >   
   > It was intended to test to determine which hashes were good at   
   > producing low collisions for unknown text strings of random length.   
   >   
   >> what I'm looking for is a keyword compression algorithm; I'm thinking   
   >> of replacing FORTH's existing counted-Word followed by code with a   
   >> lookup table of hashed keyword-to- code-entry.   
   >   
   > There were some conversations on this on comp.lang.forth a while ago.   
   > (I'm currently way behind on reading and replying to posts there ...)   
   >   
   > A hash should improve the speed of compiling the dictionary, app code,   
   > and improve lookup's via FIND etc (or whatever Forth word ANS uses   
   > instead of FIND ... PARSE?).  However, this shouldn't have much effect   
   > on code speed, as the dictionary lookups are minimal or non-existent at   
   > runtime.  In other words, lookups should only occur for use of FIND   
   > entered interactively by the user, or when defining a new word, i.e.   
   > compiling a new colon-def.   
   >   
   >> No need to store the actual Word literal.   
   >   
   > Are you replacing just the count or the count and string?   
   >   
   > If the latter, how do you distinguish one word from another when a hash   
   > collision occurs without having the original name to compare?   
   >   
   > If the former, that's a violation of ANS which requires a single char   
   > for the name length of a Forth word in the dictionary.  See COUNT.   
      
   This is archaic and I wouldn't support it; ANS should not have hardcoded   
   the position or size of COUNT, IMO.   
   []   
   >   
   > Also, any non-standard format for the count and name also won't pass   
   > Hayes Core tests, as the test explicitly constructs counted strings   
      
   Ludicrous.   
      
      
   > Also, the word list isn't fixed in Forth.  So, anyone can define a new   
   > word any time Forth is in interactive mode.  This could collide with   
   any   
   > prior word, although it sounds like you're not really having an issue   
   > with collisions yet.   
   >   
   Sure, I was hoping there'd be some headroom.   
      
   > I'm also guessing that you're not going to allocate 128KB (or more) for   
   > a lookup table, e.g., 64KB for hash, 64KB for paired code address.   
      
   Far too much space wasted!   
      So,   
   > your "compacted" lookup table will still need to traverse the hash   
   > values until you find the matching hash, either by using comparisons   
   > and branches or by using a linked-list.   
      
   It would have been a straight list to "repnz scasw" through, then pick up   
   the corresponding address from a 2nd table.   
      
   >   
   > Using comparisons and branches in assembly to traverse the "compacted"   
   > lookup table of hash values also means you'd need to be able to compile   
   > assembly into the lookup table at runtime when adding additional   
   > hash values to the table to skip unused values.  I.e., you'll probably   
   > need Forth's ;CODE word etc.   
   That was the next "idea"; just have a compiler; the interpeter would   
   compile and execute the current line.   
   >   
   > Forth's dictionary is usually set up as a list-linked list.   
   That's what I was hoping to avoid.   
      
   Thanks for typing all that!   
      
   --   
   Bah, and indeed, Humbug.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)