You're absolutely right, formal computational geometry is more biased towards exact algorithms and their associated complexities - specifically solving problems that more often than not have a geometric structure associated with them.
It is however fun from time to time to have some visual tangible results too otherwise things do get a bit dry.
@schoen You do make some very good points, the wave lengths in this list are based on the assumption of pure colour forms using Dan Bruton's Spectra approximation. http://www.physics.sfasu.edu/astro/color.html
Furthermore as you can see in the list composite colours such as white, gray and black have undefined values.
Spirit is a far more extensive library. It supports more than just lexing.
This library is much simpler without many of the features found in Spirit on the other hand it is faster in both compilation times and running times when lexing.
@Safety1stClyde Thanks for the question, I'll try my best to give provide an answer.
The example demonstrates how a given message, is initially processed (encoded) to add forward error correction symbols to it, then byte (or symbol) errors added to the message.
Subsequently the message coupled with the FEC undergoes decoding which corrects the errors previously added resulting in the original message.
The underlying scheme utilized is called Reed-Solomon error correcting code, and is used in many different area, such as data communications, data storage, cryptography etc.
@demerphq: Thank-you for these stats, and the links. I'll definitely be updating the article with the missing hash functions and adding some of the links you've provided to the links section.
My intent is to over time make the article as comprehensive as possible, but to also keep it accessible to the general public.
@bogomipz: The explanation provided by psyc is spot on. Please do note that I've updated the article with explanations for both 'Internal State' and the corresponding 'Finalize' process.
> "They aren't the same thing at all, and you should not confuse them. "
You're absolutely right. The term "idea hash function" was what I was after all along - I just couldn't find a formal definition of it. In any case I've updated the article accordingly. Thank-you for your review and comment.
@Rurban (Reini Urban): wrt to your first point, general purpose hash functions being modeled as PRNGs, I believe that statement to be correct. It is definitely the case when analysing hash function behaviour in contexts such as bloom filters, hash tables etc.
With regards to the definition of perfect hash functions - if you had read the sentence before the one you have quoted, you would have notice that the formal definition for a perfect hash function has been given in the article as:
> "In general there is a theoretical hash function known as the perfect hash function for any group of data. The perfect hash function by definition states that no collisions will occur meaning no repeating hash values will arise from different elements of the group."
It then goes on to talk about the practicalities of perfect hash functions (deriving them etc), then makes a statement that generally a perfect hash function is one that has the least collisions - I agree that it is an intentional weakening of the formal definition, but it is generally the most practical one - as there is no guarantee that one can always find a "perfect hash function" for any arbitrary set of values in sub-polynomial time.
----
wrt the collection of hash function, take note that the article is
broken into the following sections:
1. What is a general purpose hash function
2. Designing and implementing general purpose hash functions
3. Uses of hash functions
4. Example general purpose hash functions (popular ones or written by leaders in the field, and dummies such as myself)
5. Downloads
So could you clarify what it is you meant by:
> " last section is a bit misleading. First he talks about hashing in general and then he introduces his implementations of hash functions"
what specifically was misleading in the article? I'm confused, could you please clarify.
----
wrt:
> "DJB: "It is one of the most efficient hash functions ever published."
The statement is _not_ incorrect, it is indeed one of the most efficient hash functions out there, it may not be the MOST efficient or in other words "the number one hash function", but it's there at the top - I think you may have jumped the gun on that one too.
To further that, your comment: " Nonsense. FNV is considered the generally most efficient"
Lets have a look and see if that's true, the following are pseudo code representations of the mixes for each of the hash functions:
DJB: hash = ((hash << 5) + hash) + msg_byte
FNV1: hash = hash ^ msg_byte * FNV_prime
Unless you have a really bad shift operation (eg: having no barrel shifter present), then I can't see how FNV1 can be significantly more efficient than DJB - but then again, the compiler may optimize the shift right by 5 as a multiply by 32 for targets where the mul is faster than the shift...
But lets step back a bit and consider the following:
Is hash function efficiency that important when neither of the hash functions DJB or FNV1 posses good distributive qualities?
https://www.partow.net/programming/makefile/index.html