ICODE-ADC/lammps
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

remove trailing whitespace

Browse Source
This commit is contained in:
Axel Kohlmeyer
2019-03-26 11:17:21 -04:00
parent 1266b866e0
commit fff28a8666
9 changed files with 126 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/hashlittle.cpp
View File

@ -43,7 +43,7 @@ This was tested for:
the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
is commonly produced by subtraction) look like a single 1-bit
difference.
* the base values were pseudorandom, all zero but one bit set, or
* the base values were pseudorandom, all zero but one bit set, or
all zero plus a counter that starts at zero.
Some k values for my "a-=c; a^=rot(c,k); c+=b;" arrangement that
@ -53,7 +53,7 @@ satisfy this are
14 9 3 7 17 3
Well, "9 15 3 18 27 15" didn't quite get 32 bits diffing
for "differ" defined as + with a one-bit base and a two-bit delta. I
used http://burtleburtle.net/bob/hash/avalanche.html to choose
used http://burtleburtle.net/bob/hash/avalanche.html to choose
the operations, constants, and arrangements of the variables.
This does not achieve avalanche. There are input bits of (a,b,c)
@ -92,7 +92,7 @@ produce values of c that look totally different. This was tested for
the output delta to a Gray code (a^(a>>1)) so a string of 1's (as
is commonly produced by subtraction) look like a single 1-bit
difference.
* the base values were pseudorandom, all zero but one bit set, or
* the base values were pseudorandom, all zero but one bit set, or
all zero plus a counter that starts at zero.
These constants passed:
@ -169,7 +169,7 @@ uint32_t hashlittle( const void *key, size_t length, uint32_t initval)
}
/*----------------------------- handle the last (probably partial) block */
/*
/*
* "k[2]&0xffffff" actually reads beyond the end of the string, but
* then masks off the part it's not allowed to read. Because the
* string is aligned, the masked-off tail is in the same word as the
@ -314,9 +314,9 @@ uint32_t hashlittle( const void *key, size_t length, uint32_t initval)
#else /* PURIFY_HATES_HASHLITTLE */
/* I don't know what it is about Jenkins' hashlittle function, but
* it drives purify insane, even with VALGRIND defined. It makes
* it drives purify insane, even with VALGRIND defined. It makes
* purify unusable!! The code execution doesn't even make sense.
* Below is a (probably) weaker hash function that at least allows
* Below is a (probably) weaker hash function that at least allows
* testing with purify.
*/
#define MAXINT_DIV_PHI 11400714819323198485U