johnmay/beam

SMILES Toolkit

beam's Issues

SMILES parse error on non-smiles

50-00-0 throws array index out of bounds.

Missing git tag for release v1.3.3

This repository seems to lack git tags for some of the releases, for example, the most recent one, v1.3.3. Could you please add it?

Problem parsing tetrahedral stereochemistry with ring closure as last element

(With CDK2.1) The following SMILES strings represent the same molecule:

[C@]1(Cl)(F)I.Br1
[C@@](Cl)1(F)I.Br1
[C@](Cl)(F)1I.Br1
[C@@](Cl)(F)(I)1.Br1

The last SMILES string triggers an exception:

org.openscience.cdk.exception.InvalidSmilesException: org.openscience.cdk.exception.InvalidSmilesException: could not parse '[C@@](Cl)(F)(I)1.Br1', Invaid number of verticies for TH1/TH2 stereo chemistry

Is "C0CCCCC%0" a valid SMILES?

beam/core/src/test/java/uk/ac/ebi/beam/OpenSMILESSpecificationTest.java

Line 261 in 335ee67

roundTrip("C0CCCCC%0",

Is "C0CCCCC%0" a correct SMILES string? I think it should be "C0CCCCC%00" or "C%00CCCCC%00".

Quote from the OpenSMILES Specification:

Two-digit ring numbers are permitted, but must be preceeded by the percent "%" symbol, such as "C%25CCCCC%25" for cyclohexane. Three-digit numbers and larger are never permitted. However, note that three digits are not invalid; for example, "C%123" is the same as "C3%12", that is, an atom with two rnum specifications.

The digit(s) representing a ring-closure are interpreted as a number, not a symbol, and two rnums match if their numbers match. Thus, C1CCCCC%01 is a valid SMILES and is the same as C1CCCCC1. Likewise, C%00CCCCC%00 is a valid SMILES.

InvalidSmilesException should be public

Graph.fromSmiles throws the checked exception InvalidSmilesException, but this class is package protected which complicates catching it. Probably InvalidSmilesException should be public.
An alternative fix would be to declare Graph.fromSmiles as throwing an IOException as InvalidSmilesException extends from this.

Handle molecular hydrogen normalisation in generated SMILES.

[HH] should expand to [H][H]
[2HH] should expand to [2H][H]

etc.

[HH] is illegal, but this softerware does't throw any exception.

    @Test
    public void two_adjacent_h() throws IOException {
        Graph g = Parser.strict("[HH]");
    }

The test runs successfully, but [HH] is illegal!

Using matching implementation in jgrapht

Hi John,
I'm one of the developers/maintainers of the open source graph library JGrapht . I'm currently revising some of the matching algorithms in our library. While doing so I came across your matching implementation for maximum cardinality matchings (beam/core/src/main/java/uk/ac/ebi/beam/MaximumMatching.java). It seems that this implementation is faster than the implementation we currently have in our library. Therefore, with your permission, I would like to include your version in the library. Obviously, you'll remain the author of the code, and you'll be mentioned on our 'Contributors' page. No additional effort from your side is required.

I made some modifications to your matching code to make it compatible with jgrapht:
Proposed matching implementation in jgrapht
(This is not the final version; I'll have to do some additional testing, streamlining and cleanup )

Thanks!

Please add a "how to cite" section

... reflecting how you like Beam to be cited. Maybe it is an idea to put release 0.9.1 on ZENODO, because I could use that DOI to cite Beam.