From: Eccles, David
> Possibly some more insights from the Vertex code?
Okay, I think I've got it. The insight arrived in my head after I was
changing some other code in the Vertex class:
void Vertex::addIngoingEdge_ClassicMethod(Kmer*vertex,Kmer*a,int k){
uint8_t s1First=a->getFirstCode(a->isColorSpace());
// add s1First to edges.
uint8_t newBits=(1<<(s1First));
if(*vertex==m_lowerKey){
m_edges_lower=m_edges_lower|newBits;
}else{
m_edges_higher=m_edges_higher|newBits;
}
}
[first line modified by me to shift Kmer code into the Kmer class]
I noticed the shift left by a number dependent on the base code (A is shifted
left 0 times, C once, and so on), and storage in m_edges_lower/upper via the
bitwise OR. I guess I didn't see it in the other functions because of the
double-shifts that were being done.
So, each Vertex object can store all possible incoming/outgoing edges by
using only 16 more bits, and generate full Kmers describing those edges by
unpacking the bits. The '_getIngoingEdges' function pushes bases 'upwards',
and fills in the ingoing edges for the first base, and (at a guess), the
'_getOutgoingEdges' does similar by pushing down, and filling in the last
base. Am I roughly on the right track? If so, I think I can probably continue
plodding along, and shift some more of this base-shuffling code out of
commonFunctions.cpp and into the Kmer class where it is easier to adjust to
represent my new Kmer structure.
-- David Eccles
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Denovoassembler-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/denovoassembler-users
