Felipe Almeida Lessa <felipe.le...@gmail.com> writes: >> Handling the Num instance would be tricky, some of the operations >> would be wrong (e.g., literal 0 of type (Num a) => a would not be >> shifted properly) and others would be confusing (e.g., you don't add >> two 1-based offsets)
*shudder*. I don't think we want a Num instance. > I believe this will be a great source of confusion. I propose that we > use only one kind of Offset. The frontend may use +1 or -1 where > appropriate. I was thinking that we might want to keep e.g. Blast results' original offsets (which I believe are 1-based), so that you don't need to convert in order to do non-transforming operations (e.g. select a subset of results). Using a different type would be good, since it would catch inadvertent mixing of conceptiually different values. Thus my call for a general Alignment class or data type, converting to (or accessing through) Alignment should convert to standard choices, and make things comparable - also alignment from different tools. (Does that make sense?) -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Biohaskell mailing list Biohaskell@biohaskell.org http://malde.org/cgi-bin/mailman/listinfo/biohaskell
