Re: universality of codons to amino acids


Kleuskes & Moos wrote:
> wade.hines@xxxxxxxxxxxxxxxxxxxxx schreef:
>
> <snip>
>
> > > In dutch that's referred to as either
> > >
> > > * "Seeking nails at low-tide"
> > > * "Fucking ants"
> > >
> > > So take your (nit)pick.
> >
> > Hmmm. I know some few things about look up tables. I know some few
> > things about The Genetic Code. Calling it a look up table is a
> > reasonable metaphor.
>
> tRNA (i just learned) is rather less than exact in its mapping, so the
> metaphor is not a very good one, in my opinion.
>
> > When doing bits of bioinformatic software, a hash table for codons
> > that converts them to amino acids is actually a common theme.
>
> Hashtable != lookuptable.
>
> Just like
>
> DNA != RNA, eventhough both consist of sequences of amino-acids. If I
> were to tell you that RNA is a kind of DNA, you would correct me,
> right?

You've been corrected but I'm too thick to see the full flavor
of Hashtable != lookup table. Seems to me the difference is
mapping the hash key to an index in a lookup table that has
a number of entries that are empty. If the first hashing
function doesn't produce unique keys, another layer can
resolve things or you can rework the hashing logic. For many
uses, one can leave it up to the compiler and ignore the details.

Two lookup tables I use often are amino acid to a mass
and a mass to an amino acid.

For the first, I convert each single letter AA to a number
from 0-25 and use it as an index of an array containing
amino acids. masses[ aa - 'A'] = mass_of_amino_acid_aa
for aa A-Z. BJOUXZ are often left undefined. I'm often amazed
at how few bioinformaticists use these simple mappings.

When writing quicky perl code, I often resort to aas{aa}
and don't care about the overhead of the hash vs. the
array. How long it takes to write and debug something
is frequently more important than operational efficiency.

I can do the same for ATCG with whatever mapping I like
but something like 0,1,2,3 and a triplet being
first base * 16 + second base *4 + third base gives a
nice EZ 0 - 63. We can map that to AAs.




> > The genetic code is perhaps even a layed hash table where some
> > entries are complete with a partial entry key and other entry
> > keys point to secondary hash table, sort of like perl programming
> > gone wild.
>
> Lookup table: a consecutive set of entries you can address by an index,
> used to map the index to some other value very fast. It has no
> operations except a (very simple and hence very fast) indexing
> mechanism.

> Hash tables, otoh, can map any key to any value. strings to numbers,
> strings to strings, etc, but are a lot slower and have more overhead.

Fine. tRNAs have the first base registered to the leftmost 2 bits
of a 6 bit index. The middle base to the middle 2 bits. The last
to the rightmost 2 bits. The functionality called wobble means
that some bits don't need to be read as any read is equivalent.
You can frame that multiple ways but it looks like a lookup
table to me.

Or, maybe it's more like a hash table as the aa-tRNA synthetases
and tRNAs are like a hashing function converting an actual AA to
to an mRNA triplet.

> Hence a lookup-table can be regarded (if you must) as a hash-table
> having the hash-function H(x) = x, which obviously does not have any
> collisions.

> > Now perhaps you've got some sacred version of look up tables
> > that isn't the same as those I've used for twenty odd years
> > to translate from DNA to amino acids, or masses to amino acids,
> > or amino acids to masses.
>
> I'd use a lookup-table instead of a hash-table. The advantages are
> obvious.

> 1. No hash function needed, which is relatively expensive if the table
> is small (like the examples you mention), and which requires some
> expertise in order to select an appropriate hash function.
> 2. Less RAM footprint.
> 3. Less chance of nasties such as collisions, which need handling (by a
> simple linked list, for instance).
> 4. Since the query mechanism for a lookup table is trivial and that of
> a hash-table is not, there is much less chance of bugs.
>
> Translating codons to actual indices is trivial and is left as an
> excersise for the student.

There are actually better and worse ways to do it based on those
pairs of triplet codons that are equivalent but this depends on
the intended usage. When translating from amino acids into all
possible nucleotide matches it can make things simpler but for the
majority of applications doing so tends to make code that much
harder to follow for only modest improvements in performance.

> > But for my money, I can't see what
> > that sacred version would be. Perhaps you could be so kind
> > as to educate this idiot as well.
>
> I never called anyone an idiot, so that qualification is yours alone.
>
> In your defence I can say that some also consider associative arrays
> valid implementations of lookup-tables, though that is not a definition
> i'm familiar with.
>
> For hash-tables see:
>
> Knuth, The Art of Computer Programming, Vol 3, pp 513-549.
> Lookup-tables are so trivial, Knuth does not describe them.

.

Loading