Saturday, March 21, 2009
Love Hurts
Love hurts, love scars,
Love wounds, and marks,
Any heart, not tough,
Or strong, enough
To take a lot of pain,
Take a lot of pain
Love is like a cloud
Holds a lot of rain
Love hurts, ooh ooh love hurts
I'm young, I know,
But even so
I know a thing, or two
I learned, from you
I really learned a lot,
Really learned a lot
Love is like a flame
It burns you when its hot
Love hurts, ooh ooh love hurts
Some fools think of happiness
Blissfulness, togetherness
Some fools fool themselves I guess
They're not foolin me
I know it isn't true,
I know it isn't true
Love is just a lie,
Made to make you blue
Love hurts, ooh,ooh love hurts
Ooh,ooh love hurts
[guitar solo]
I know it isn't true,
I know it isn't true
Love is just a lie,
Made to make you blue
Love hurts, ooh ooh love hurts
Ooh ooh love hurts
Ooh ooh...
Thursday, February 05, 2009
Keggin Isomers
This post introduced my understanding of Keggin structure. Keggin structure, also called Baker-Figgis-Keggin structure, is a well known structrual scalfold for heteropoly acids and other inorganic compounds. Below is extracted from the structure [AlO4Al12(OH)24(H2O)12]7+ (often called as Al13) determined by the X-ray crystallograph.
Al13, &epsilon Keggin Structure
α Isomer, Td
α Isomer, Wireframe Model
&epsilon Isomer, Td
&epsilon Isomer, Wireframe Model
&beta Isomer, C3v
&gramma Isomer, C2v
&delta Isomer, C3v
Al13, &epsilon Keggin Structure
α Isomer, Td
α Isomer, Wireframe Model
&epsilon Isomer, Td
&epsilon Isomer, Wireframe Model
&beta Isomer, C3v
&gramma Isomer, C2v
&delta Isomer, C3v
Wednesday, February 04, 2009
Building a Cheminfomatics System in M7
In the past two weeks, I need to build an in-house compounds collection database. Well, there are many open and commercials ones available on Internet. However, they do not serve my needs. Then I decide that I might be able to build one of my own. I have no previous experience in database building. So I started out by thinking if I can use Mathematica or Lisp to build a database of its own without relying on the third-party engines. Later I realized the enomorus work that will require.
After searching the documentation of Mathematica 7, I found it provides an easy-to-use interface for many database systems, such as MySQL and Oracle. Although the mathematica version of SQL functions is quite limited and you cannot use those functions as free as normal functions (they have to be able to converted to SQL grammar), you could always use SQLExecute[] to write any SQL sentences. The interface function takes care of data types conversion. I then chose the open source MySQL as my database engine.
Mathematica 7 introduced new Import capabilities for SDF and SMILES files besides its support for MOL2 and PDB. It also provides a closed source database called ChemicalData. At the beginning, I thought these functionality may save me a lot of time since most of my data sources are available in either SDF or SMILES format. After trying out several big commercial catalogs, I abandoned this idea. Real life files are not 100% in conform with the file format standards, but filled with all sorts of odds. Import function fails at so many situations that I have to write many wrap-up codes for taking care of errors. Then I started wring my own parser codes and the job was much simpler than I thought. The SDF format is quite old and its definition is in the FORTRAN style.
Although mathematica is not much helpful in parsing the input files, it is a good choice for work-flow coding, pre- and post-processing of data items. Cheminformatics toolkits need time to write, but the interface to external programs of Mathematica offers a convenient pipe to employ the third-party toolkits, such as openbabel, oechem, jchem, etc.
After debugging many obvious and less obvious errors, the system is finally running smoothly. On my 2-core lenovo laptop with 2GB memory, the single-process code loads about 800,000 compounds (1.8GB on hard disk) including the redundancy check and proprieties calculation in 12 hours. And the average CPU loading is about 1.5. And the time cost per entry seems not increasing as the database increases its size dramatically.
After searching the documentation of Mathematica 7, I found it provides an easy-to-use interface for many database systems, such as MySQL and Oracle. Although the mathematica version of SQL functions is quite limited and you cannot use those functions as free as normal functions (they have to be able to converted to SQL grammar), you could always use SQLExecute[] to write any SQL sentences. The interface function takes care of data types conversion. I then chose the open source MySQL as my database engine.
Mathematica 7 introduced new Import capabilities for SDF and SMILES files besides its support for MOL2 and PDB. It also provides a closed source database called ChemicalData. At the beginning, I thought these functionality may save me a lot of time since most of my data sources are available in either SDF or SMILES format. After trying out several big commercial catalogs, I abandoned this idea. Real life files are not 100% in conform with the file format standards, but filled with all sorts of odds. Import function fails at so many situations that I have to write many wrap-up codes for taking care of errors. Then I started wring my own parser codes and the job was much simpler than I thought. The SDF format is quite old and its definition is in the FORTRAN style.
Although mathematica is not much helpful in parsing the input files, it is a good choice for work-flow coding, pre- and post-processing of data items. Cheminformatics toolkits need time to write, but the interface to external programs of Mathematica offers a convenient pipe to employ the third-party toolkits, such as openbabel, oechem, jchem, etc.
After debugging many obvious and less obvious errors, the system is finally running smoothly. On my 2-core lenovo laptop with 2GB memory, the single-process code loads about 800,000 compounds (1.8GB on hard disk) including the redundancy check and proprieties calculation in 12 hours. And the average CPU loading is about 1.5. And the time cost per entry seems not increasing as the database increases its size dramatically.
Monday, January 26, 2009
Pfizer buys Wyeth
2008 saw many "impossible" things happened. Super big Wall Street banks went brankrupt and Obama won the presidency of the United States. Well, in the new year of 2009, Pfizer wants to buy Wyeth for $68 billion and it would become the largest merger case if it is completed as planned.
News report from New York Times is linked as below.
http://www.nytimes.com/2009/01/26/business/26drug.html?_r=1&hp
News report from New York Times is linked as below.
http://www.nytimes.com/2009/01/26/business/26drug.html?_r=1&hp
Thursday, January 15, 2009
SMILES Parser
SMILES and Mathematica normal expression are essentially the same. Both are a presentation of a graph by breaking cycles into labeled trees. It is straightforward to parse a SMILES string into an expression so that further operations can be easily applied in Mathematica functions.
With the aid of string patterns (i.e. regular expression), recursive programing and the ability to convert a string into an expression (i.e. macro expansion), an expandable parser is not hard to write.
First, there are two kinds of information encoded in SMILES: atomic and structural information. Atomic information includes atom symbol, type, bonds, isotope weight, charge, valence, etc. Structural information includes atom order, the cyclic labeling, branches, etc. Configuration around double bonds, chirality are structural information from a chemist's viewpoint. However, they are not graphic properties in the sense of topology and can only be encoded into some predefined conventions, such as the orders of atoms. If we need independent representation form of them, we can encode such information as 3D coordinates of atoms along other information. Atomic information is very limited in SMILES and can be thought as known knowledge or can be obtained with other means. For the sake of simplicity, we may neglect it now.
We divide the parsing job into two parts, static definition of atom dictionary and all sorts of string patterns and scan function of a SMILES string.
Atom Dictionary
String Patterns
When scanning a SMILES string, we break it into basic nodes as defined in the pattern of smiAtomAny, then different cases are handled accordingly. There are three situations in general: an atomic node, an atomic node with breaking labels and a branching node.
Parse Smiles
Cycling labeled are re-organized with an unique number from the natural number sequence. Cycle breakage labeling and branching handling uses a similar mechanism: a stack-like (either in the form of a data structure or a function) data structure is used to store intermediate results. As an open symbol is met, a new item is built. When a closure symbol is met, the stored intermedate is handled and pop up one item from the stack. Otherwise, we push the item into the stack. To avoid using global variables which is convenient in recursive coding, we define the sub-functions inside smiParseSmiles.
The function was tested on the 150 smiles strings in the OpenBabel package. Total time of 30 seconds was costed on my laptop. Below is an example SMILES string and the parsed result.
Example SMILES
Normal Expression Represenation
With the aid of string patterns (i.e. regular expression), recursive programing and the ability to convert a string into an expression (i.e. macro expansion), an expandable parser is not hard to write.
First, there are two kinds of information encoded in SMILES: atomic and structural information. Atomic information includes atom symbol, type, bonds, isotope weight, charge, valence, etc. Structural information includes atom order, the cyclic labeling, branches, etc. Configuration around double bonds, chirality are structural information from a chemist's viewpoint. However, they are not graphic properties in the sense of topology and can only be encoded into some predefined conventions, such as the orders of atoms. If we need independent representation form of them, we can encode such information as 3D coordinates of atoms along other information. Atomic information is very limited in SMILES and can be thought as known knowledge or can be obtained with other means. For the sake of simplicity, we may neglect it now.
We divide the parsing job into two parts, static definition of atom dictionary and all sorts of string patterns and scan function of a SMILES string.
Atom Dictionary
smiElements:= {
{"C", 4},
{"H",1},
{"N", 3,5},
{"O",2},
{"S",2,4,6},
{"B",3},
{"F",1},
{"Cl",1},
{"Br",1},
{"I",1}
};
smiElementsAromatic:={"c","n","o","p","s","as","se"};
String Patterns
(* Need to be refined. *)
smiAtomDefault := (#[[1]] & /@ smiElements);
smiChargePatttern := (("-" | "+") ..) | (("-" | "+") ~~ DigitCharacter ...);
smiChiralPattern := ("@" ..) | ("@" ~~ DigitCharacter) | ("@" ~~ LetterCharacter ~~ LetterCharacter ~~ DigitCharacter);
smiAtomCustom := "[" ~~ DigitCharacter ... ~~ smiAtomDefault ~~
smiChiralPattern ... ~~ ("H" ~~ DigitCharacter ...) ... ~~
smiChargePatttern ... ~~ "]";
smiAtomPattern := smiAtomCustom | smiAtomDefault;
smiAtomAromatic := smiElementsAromatic | ( "[" ~~ DigitCharacter ... ~~ smiElementsAromatic ~~ smiChiralPattern ... ~~ ("H" ~~ DigitCharacter ...) ... ~~smiChargePatttern ... ~~ "]");
smiBondPattern := "-" | "=" | "#" | ":" | "/" | "\\" | ".";
smiBranchBra := "(";
smiBranchKet := ")";
smiBranchEither = smiBranchBra | smiBranchKet;
smiCyclicLabel := (DigitCharacter ~~ ("%" ~~ DigitCharacter ~~ DigitCharacter) ...) | (DigitCharacter ~~ DigitCharacter ~~ ("%" ~~ DigitCharacter ~~ DigitCharacter) ...)
smiAtomAny := ("" | smiBondPattern) ~~ (smiAtomPattern | smiAtomAromatic) ~~ ("" |smiCyclicLabel);
When scanning a SMILES string, we break it into basic nodes as defined in the pattern of smiAtomAny, then different cases are handled accordingly. There are three situations in general: an atomic node, an atomic node with breaking labels and a branching node.
Parse Smiles
smiParseSmiles[s_String, type_: "String"] :=
Module[{smiParseAtom, smiParse,smiGetLabelIndex, smiParseCyclicLabelMeta},
smiGetLabelIndex[i_String] := Module[{pos, temp}, ...];
smiParseCyclicLabelMeta[bond_String, y_String] := Module[{z, zz, zzz}, ...];
smiParseAtom[ss_String] /; StringMatchQ[ss, smiAtomAny] :=StringReplace[...];
smiParseAtom[ss_String] /; StringMatchQ[ss, smiBranchBra] := (...);
smiParseAtom[ss_String] /; StringMatchQ[ss, smiBranchKet] := (...);
smiParse[ss_String] := Block[{$RecursionLimit = Infinity},StringReplace[ss, ...];
StringReplace[s,
StartOfString ~~ a : (smiAtomPattern | smiAtomAromatic) ~~
c : ("" | smiCyclicLabel) ~~ rest___ ~~ EndOfString :>
"Molecule[\"" ~~ a ~~ "\"" ~~
If[StringQ[c] && StringLength[c] > 0,
smiParseCyclicLabelMeta[
If[StringMatchQ[a, smiAtomAromatic], ",Aromatic",
",Single["], c], ""] ~~
If[StringQ[rest] && StringLength[rest] > 0, smiParse[rest]] ~~
"]"]
];
Cycling labeled are re-organized with an unique number from the natural number sequence. Cycle breakage labeling and branching handling uses a similar mechanism: a stack-like (either in the form of a data structure or a function) data structure is used to store intermediate results. As an open symbol is met, a new item is built. When a closure symbol is met, the stored intermedate is handled and pop up one item from the stack. Otherwise, we push the item into the stack. To avoid using global variables which is convenient in recursive coding, we define the sub-functions inside smiParseSmiles.
The function was tested on the 150 smiles strings in the OpenBabel package. Total time of 30 seconds was costed on my laptop. Below is an example SMILES string and the parsed result.
Example SMILES
OC(=O)C1=C(C=CC=C1)C2=C3C=CC(=O)C(=C3OC4=C2C=CC(=C4Br)O)Br
Normal Expression Represenation
Molecule["O",
Single["C", Double["O"],
Single["C", Single[R[1]],
Double["C",
Single["C", Double["C", Single["C", Double["C", Double[R[1]]]]]],
Single["C", Single[R[2]],
Double["C", Double[R[3]],
Single["C",
Double["C",
Single["C", Double["O"],
Single["C",
Double["C", Double[R[3]],
Single["O",
Single["C", Single[R[4]],
Double["C", Double[R[2]],
Single["C",
Double["C",
Single["C", Double["C", Double[R[4]], Single["Br"]],
Single["O"]]]]]]]], Single["Br"]]]]]]]]]]]
Thursday, January 08, 2009
Represenation of Molecules
There are many ways to represent molecules in computerized world, such as connection table, z-matrix, cartesian lists, SMILES, INCHI, SDF, MOL2, PDF, etc. Various kinds of formats serve for different purpose. For the most use in cheminformatics area, the format should be efficent and compact in terms of size, import and export, all sorts of operations. For the internal usage, the human readability is not so important. A molecule can be naturally viewed as a labeled graph. Robert B. Nachbar proposed a hierarchical data structure (a tree) for genetic programming in his molecular evolution studies. Like in SMILES format, rings are broken to turn a cyclic graph to a tree and the broken bonds are labeled with a label. He called such format Normal Expression represenation. In Mathematica, a sample presenation is as follows. This view is not only natural but also efficient in parsing though it seems clumszy at the first sight.
Ball-Stick Model
Mathematica Normal Expression
Tree Structure
Although the molecular evolution has been continued by researchers at the Unveristy of Leiden (they even set up a company for selling their software product), the represenation format has been abondoned. Instead, they adopt the so-called TreeSMILES format which is nearly identical with SMILES. Since LISP was used in their implementation. I don't see the reason why abondon such format. Actually, in Lisp, the format merits on another advantage: the closure scoping and compiling on-fly make it possible to present a molecule in a compiled function. For such an implementation, not only is the efficiency is high, but also the coding is terse (the molecular represenation function also serves as accessor and other related functions).
Ball-Stick Model
Mathematica Normal Expression
Tree Structure
Although the molecular evolution has been continued by researchers at the Unveristy of Leiden (they even set up a company for selling their software product), the represenation format has been abondoned. Instead, they adopt the so-called TreeSMILES format which is nearly identical with SMILES. Since LISP was used in their implementation. I don't see the reason why abondon such format. Actually, in Lisp, the format merits on another advantage: the closure scoping and compiling on-fly make it possible to present a molecule in a compiled function. For such an implementation, not only is the efficiency is high, but also the coding is terse (the molecular represenation function also serves as accessor and other related functions).
Wednesday, January 07, 2009
Reader on Screen
The Reader is a novel about the relationship between a teenager boy and a Nazi policewoman during WWII. I first read it four (or eight?) years ago. As I remembered, I could not keep on reading it through once I started. The work has all characteristics of a masterpiece, a touching angle about a big historical event, the conflict between humanity and justice, desire and sex, etc. Just an unforgetable reading experience as the author unfolding his story with the heroine, Hanna.
The same title on today's New York Times caught my attention. By clicking into the link, I was eager to find if this movie is based on the novel that I read. The running title, "How far would you go to protect a secret?", does not ensure me, but as I read the story summary, all the feelings got freshen-up.
The movie, starred by Kate Winslet and Ralph Fiennese, has won several gold globe nominations. I am eager to see it, however, not sure if I should hold much expecation on the movie.
Subscribe to:
Posts (Atom)
