

  (Source: AP)
DNA comes from sequencing of Neanderthal toe-bone found in Siberia


I. Getting to Know Our Neighbors, Distant Ancestors





Denisova cave
[Image Source: Current Biology/Science]


II. Contamination, Region Variance Leave Picture Only Mostly Complete




Family tree




Source: MPI

Comments     Threshold


What kind of idiotic file format...
By Shadowmaster625 on 3/21/2013 10:01:33 AM , Rating: -1
The entire human genome is 3.2 billion base pairs. That is 3.2 billion bits with a 0 representing a guanine-cytosine pair, and a 1 representing an adenine-thymine pair. 3.2 billion bits is only 400MB. So there is really only 400MB of raw DNA data in the human genome. So why are these files so much larger? I'm sure you need a few extra bits if you want to have indexes for individual genes, but that's it. Just a couple extra megabytes would take care of all the indexing overhead. Wow these guys are wasting hundreds of gigabytes on nothing! Must be a govt funded operation....

By retrospooty on 3/21/2013 10:09:24 AM , Rating: 2
RE: What kind of idiotic file format...
By freeagle on 3/21/2013 11:06:43 AM , Rating: 2
An expert on DNA indexing has spoken...

A binary seach tree, where each leaf would represent one base pair, would contain (3.2e9 - 1) vertices (roughly, the - 1 is there just to draw the relationship between vertices and leafs in general). Each vertex needs to somehow point to both of its children. Each such pointer requires at least 4 bytes, so thats 8 bytes per vertex, times 3.2e9 is 25.6e9 bytes, so 23.84 GB. Granted, you could compress such a data structure when storing into a file, but I assume you need more metadata for each vertex than just pointers to its children...

I'm not saying this is what they use to index the the bases, I'm no DNA data indexing export either, but it certainly is not "just a couple extra megabytes"

RE: What kind of idiotic file format...
By TheEinstein on 3/21/2013 1:06:28 PM , Rating: 2
3.2 billion base pairs is actually 3.2 billion bits.

Since effectively the data is RAND compression is highly unlikely to save many bits

3.2 /8 = 400 million bytes. He was correct in his 400mb size file.

Unless there is 'empty pairs' of sorts. There is no need for vertexes if you run sequential.

Now given if there is variable count per specie (I am no genetitsist (sp?)) then the solution is simply count til finished

You only need to run a tree if there is a variable placement based upon previous results and then only if the system is not self indexing.

By cashkennedy on 3/21/2013 6:40:18 PM , Rating: 2
I would imagine there is a bunch of extra information to allow the data to be accessed / searched faster, such as what proteins various sections lead to , and possibly a index column that says what numerical position each base pair is in. Im no expert on databases though, but there are plenty of retarded ways to make databases, and although text files of pure data are nice and small they take forever to search.

By MantisLion on 3/22/2013 2:10:38 AM , Rating: 1
Just so you know, .BAM files are alignment files, that is, they are stacks of individual DNA sequences from a sequencing machine aligned together to form a final sequence. This is done to ensure that each base is sequenced multiple times for maximum accuracy, as next-generation sequencing techniques sacrifice some quality of base call for quantity of sequencing. It's not just the raw end sequence they have there, otherwise you would be correct in your 400MB figure.

I've worked with .BAM files that have been >30GB, but only covering approximately 50 megabases worth of actual sequence data, simply because the coverage (sequencing depth) of each base was on average 250x.

