mol-hume

Molecular descriptors computed in C++, verified column by column against RDKit and Mordred.

mol-hume computes up to 1,269 descriptors per molecule in about 285 microseconds, from a single call, plus a 2,048-bit ECFP alongside them. Of the descriptors, 1,109 reproduce ones that RDKit or Mordred already define, and 160 are new. Nothing is computed in Python.

The default is the reduced 622-column minimal set, which is also 17% faster to compute because the columns it drops are no longer calculated. Pass columns="full" for all 1,269.

pip install mol-hume

import molhume

X = molhume.featurize(["CCO", "CC(=O)Oc1ccccc1C(=O)O"], standardize="none")
# X -> (2, 2670) float64: the 622 `minimal` descriptors then 2,048 ECFP bits, ready for a model

xgboost.XGBRegressor().fit(X, y)

One array, not a tuple. The column names do not change from call to call, so returning them every time is something you would unpack and discard; ask for them when you need them, and they come back in the same order for the same flags:

df = pandas.DataFrame(X, columns=molhume.feature_names())

Pass the same flags to both and the names line up: feature_names(fingerprint=False) for the descriptors alone, feature_names(columns="full") for all 1,269.

Which columns

One parameter, four ways to answer it:

molhume.featurize(smiles, columns="minimal")      # 622 -- the default
molhume.featurize(smiles, columns="full_no_new")  # 1,109 -- what RDKit or Mordred already define
molhume.featurize(smiles, columns="full")         # all 1,269
molhume.featurize(smiles, columns=["TPSA", "AvgIpc", "BCUTc-1h"])   # exactly these, in this order

molhume.column_set(name) returns the names in any of the three sets, and molhume.ALL_COLUMNS lists every name a manual selection can use.

Since 0.7.0 this decides what is COMPUTED, not just what is returned. A descriptor family none of whose columns you asked for is not calculated at all, and neither are the individual eigensolves of the spectral family, which is the most expensive of the nineteen. The output is identical either way -- tests/test_families.py checks every family and every set against an ungated run, cell for cell -- but a narrow selection is now cheaper as well as smaller. Measured on 1,200 molecules of cpp/hard.smi at one thread, against the ungated 918 us/mol:

selection	us/mol
`columns="minimal"` (622)	762	17% faster
`columns="full_no_new"` (1,109)	908	1% -- within noise
`columns="full"` (1,269)	900	2% -- within noise
`columns=["TPSA", "ExactMolWt", "SLogP"]`	288	69% faster

The two full sets gain nothing, which is the honest result: they ask for every family, so there is nothing to skip.

The one decision you have to make

standardize has no safe default, so leaving it unset warns once and tells you the options. Descriptors are computed on the graph you hand them: a salt, a tautomer and a charge state are three different molecules, and no library can guess which one you meant.

value	what it does
`"none"`	featurize exactly what you supplied
`"canonical"`	SMILES round-trip, nothing else
`"cleanup"`	RDKit `MolStandardize`: normalize, largest fragment, uncharge
a callable	your own `Mol -> Mol`

Passing "none" explicitly is a decision and is silent; omitting it is not, and warns.

Flags

flag	default	what it controls
`standardize`	`"none"` (warns if unset)	what molecule the numbers describe
`threads`	`0`	descriptor-block workers; `0` is one per hardware thread. Pass `1` if your own code is already parallel — but see the timing note below, because it costs about 3x
`fingerprint`	`True`	append `fp_size` ECFP bit columns after the descriptors, so descriptor column indices never shift when the flag changes. Turning it off saves about 30 us/molecule that cannot be threaded
`fp_radius`	`3`	ECFP radius
`fp_size`	`2048`	ECFP bits
`columns`	`"minimal"`	`"minimal"` (622), `"full_no_new"` (1,109), `"full"` (1,269), or a list of names in the order you want them. Decides what is computed as well as what is returned
`on_error`	`"nan"`	unparseable SMILES: `"nan"` keeps the row and fills it, so the output stays aligned with the input; `"raise"`; `"skip"` drops the row, so it does not
`dtype`	`float64`	`float32` halves the memory and is what the boosting libraries convert to internally anyway
`batch_size`	`4096`	rows per batch. Affects memory, not values

featurize also takes RDKit Mol objects instead of SMILES, which skips a parse.

molhume.feature_names(**flags) gives the names for any set of flags; molhume.ALL_COLUMNS is the full list, and molhume._additional.ADDITIONAL_COLUMNS the ones that are ours.

To take one descriptor family, molhume.FAMILY_OFFSETS maps a family name to a half-open (start, stop) into ALL_COLUMNS and into the descriptor block of the output:

lo, hi = molhume.FAMILY_OFFSETS["ringcount"]
ring_counts = X[:, lo:hi]                     # 47 columns, n5Ring .. nG12FAHRing

import mol_hume works too, and is the same module object — the distribution is mol-hume, and import mol-hume is a Python syntax error, not something a package can fix.

What "verified" means

Every column was compared against its upstream definition over a 42,000-molecule corpus spanning 1 to 64 heavy atoms:

167 of 186 RDKit columns and 412 of 968 Mordred columns are bit-identical.
99.99% (RDKit) and 99.23% (Mordred) of values agree to within 1e-9.

The remainder are deliberate, documented divergences, not unexplained differences: they are cases where the upstream definition depends on atom numbering or on a Kekule choice, and therefore has no single correct answer. Every one of them is listed with a measurement in METHODS.md.

About that 285 us

That is the threaded number, with threads=0 (one worker per hardware thread), which is the default. The descriptor block is the parallel part, so the single-threaded figure is very different. Measured on a 12-thread M-series laptop, 4,000 corpus molecules:

	us/molecule
`threads=0` (default, 12 threads)	282
`threads=0`, `fingerprint=False`	247
`threads=1`	861
`threads=1`, `fingerprint=False`	846

So threads=1 costs roughly 3x, not 12x — the per-molecule boundary work does not parallelize. Pass threads=1 when your own code is already parallel across processes; leave it at 0 otherwise. Quoting a per-molecule cost without saying which of these it is makes the number meaningless, so always say.

The RDKit range

mol-hume requires rdkit>=2024.09.1,<2026.09, and this is a hard requirement rather than a preference. The library reads RDKit's MolPickler blob directly — a large part of where the speed comes from — and that format is explicitly not a stable API. Outside the range that has been measured, mol-hume refuses to import rather than misparse a molecule into wrong numbers with no symptom.

Within the range, the pickle format is checked rather than assumed: RDKit 2026.03 writes a different format version from 2025.09, and it is accepted because 4,000 corpus molecules pickle to bytes that differ only in the version triple, and all 1,269 columns over 8,000 molecules come out bit-identical. Widening it for a future release is one command — tools/check_rdkit_release.py — plus, if the blobs really changed, work on the reader. See MAINTENANCE.md.

The upper bound is loose on purpose. It is a courtesy to resolvers — it stops a fresh install picking an RDKit years newer than anything measured — not a claim that 2027 will work. If the pickle format does change, featurize raises an error naming your RDKit and what to do, the package still imports, and featurize_blocks(reader="api") still works on any RDKit at all, because it goes through RDKit's supported Python API.

Within that range, values are quoted against RDKit 2025.9.2 specifically. RDKit's perceived atom and bond properties drift across releases, so a different RDKit inside the range can still move values in the last digits.

Why 1,269 and not 1,539

The implemented set was 1,539 columns. Pairs that carry the same information were removed by a greedy cover in ascending compute cost: a column is dropped when some cheaper surviving column predicts it at |Spearman| >= 0.99 on ranks, and that has to hold in every one of five heavy-atom strata, not just on the pooled corpus, so a correlation that only exists because small and large molecules sit at opposite ends of both scales does not count. Columns that are NaN more than half the time, or that take one value for 99.9% of molecules, are dropped as unusable. What survives is 1,269.

A reduced column set

minimal-v2 is a 622-column subset of the 1,269, and since 0.7.0 it is the default:

X = molhume.featurize(smiles)                     # these two are the same call
X = molhume.featurize(smiles, columns="minimal")

It is a set, not a ranking. Every column was removed for one of three reasons, and none of them is a variance threshold:

the same physical quantity in different units — three electronegativity scales, atomic mass against atomic number, polarizability against volume. Read from the definitions, because no correlation cutoff separates "0.995, same construct" from "0.99, genuinely different";
already carried by the ECFP that ships alongside, or a duplicate of a count we already emit — 13 fr_* flags go for the second reason (fr_halogen is [F,Cl,Br,I] against nF/nCl/nBr/nI/nX; fr_Ar_N is the SMARTS n; fr_bicyclic is [R2][R2]);
an exact arithmetic identity of columns that remain — ring and constitutional counts that are sums of others, verified on two chemical spaces.

All the descriptors you would expect are in it: molecular weight, Crippen logP, TPSA, H-bond donors and acceptors, rotatable bonds, ring counts, Kappa shape, chi connectivity, Labute ASA, Balaban J, Lipinski, and 72 of the 75 fr_* substructure flags.

⚠️ The fr_* flags were dropped in 0.4.0 and restored in 0.5.0, and the reason is worth knowing. They were dropped because they are detectable from the ECFP at AUROC 1.000 — but that figure is conditional on the corpus, not just the fingerprint. On a corpus with 5.4% salts the same measurement gives a median of 0.9929 and a floor of 0.786; fr_quatN reads 0.9995 on one corpus and 0.73 on the other. A 2×2 over radius (2 vs 3) and decoder (logistic vs XGBoost) moves our median by less than 0.001, so neither explains the gap. Detectability was never sound grounds for the drop. The 62 are kept on mechanism: they encode curated assertions no structural descriptor derives — that a CYP enzyme attacks here, that a nitrogen is permanently charged, that a fragment is a toxicophore, which heteroatom sits in a ring, whether a hydroxyl is aliphatic or aromatic.

What it costs, measured

Benchmarked against the full 1,269 with the same untuned XGBoost head and the same 5-fold scaffold splits, on 29 of the 33 grid datasets:

panel	datasets	mean cost	worst
ADME & tox	10	−1.55%	+2.79%
physicochemical	6	−0.94%	+1.49%
classification	13	−0.17%	+1.99%
overall	29	−0.81%	—

Negative means the reduced set scored better. On none of the 29 datasets did the difference exceed that dataset's own fold-to-fold spread, and a sign test puts the reduced set behind on 11 of 29 (p = 0.27). So the claim is no measurable difference at 43% of the columns — not that fewer columns help.

For contrast, the retired minimal-v1 cost +3.83% on the physicochemical panel with 800 columns. v2 is smaller and that loss is gone; the difference is what the two cut on.

⚠️ The quantum panel (qm8, qm9, qm9_gap, qmugs_gap) is not yet included, and it is the one to watch: the 227-column autocorrelation block was dropped on a physicochemical ablation, and autocorrelation is a distance-resolved property correlation, which is the kind of thing an electronic-structure endpoint might lean on. See HUME_Minimal_definition.md.

Platforms

Wheels are built for the platforms RDKit itself ships, since a mol-hume wheel for a platform with no RDKit wheel could not be imported:

	CPython 3.10 - 3.14
Linux x86_64, aarch64	manylinux_2_28
macOS arm64	11.0+
macOS x86_64	10.15+, needs `rdkit<=2025.9.2` (RDKit dropped Intel Mac after that)
Windows x86_64	MSVC

No musl, no 32-bit, no PyPy — RDKit publishes none of those. The extension links only the C++ runtime: no BLAS, no RDKit library, and no NumPy ABI, so one wheel works across NumPy 1.x and 2.x.

Values are not bit-identical across architectures

This matters if you are comparing outputs between machines, and not at all if you are fitting a model. The exactness numbers above were measured on macOS arm64 with clang. The same source on x86-64 moves the last bits: 594 of the 1,269 columns under gcc, 595 under MSVC, with a maximum disagreement of 1.1e-14 of each column's range. Nothing structural changes — the NaN pattern is identical on all three.

That is not a bug that a build flag removes. The library reproduces upstream floating-point behavior, so a different libm's log and a different FMA decision are part of the result. CI measures this on every platform (tools/platform_drift.py) and the test suite asserts a bound on it, exactly rather than approximately on the reference platform.

Beware per-value relative error when you compare: several columns are differences that cancel to near zero (the centered autocorrelations, Cyclicity, DeltaMean), where a last-bit wobble reads as a relative error of 27. Compare against each column's range.

Development

uv pip install -e . --python .venv/bin/python -c constraints.txt
.venv/bin/python -m pytest tests/

The pinned RDKit in constraints.txt is the oracle every exactness claim is measured against — install with -c constraints.txt or a bare editable install will silently upgrade it. tests/ runs in seconds against a committed fixture; the full exactness verifications against RDKit and Mordred are the root-level verify_*.py, which need the corpus and a second environment. See tests/README.md.

Acknowledgments

mol-hume reproduces descriptors first defined and published by two projects, and would not exist without either:

RDKit — Greg Landrum and contributors. RDKit parses the molecule and supplies every perceived atom and bond property this library computes from, and 186 of the emitted columns reproduce RDKit descriptor definitions. Several parameter tables here are derived from published RDKit values, including the Crippen logP/MR atom-type contributions and the Hall-Kier alpha table. BSD 3-Clause.
Mordred — Hirotomo Moriwaki et al., J. Cheminform. 10, 4 (2018). 968 of the emitted columns reproduce Mordred definitions. BSD 3-Clause.

Where this library's values differ from either, the difference is deliberate and documented: those are cases where the upstream definition depends on atom numbering or on a Kekule choice and so has no single correct answer. Every one is listed with a measurement in METHODS.md.

License

BSD 3-Clause. See LICENSE.

Development Status
- 4 - Beta
Intended Audience
- Science/Research
Programming Language
- C++
- Python :: 3
Topic
- Scientific/Engineering :: Chemistry

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

mol_hume-0.7.0.tar.gz (493.5 kB view details)

Uploaded Sep 2, 2026 Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

The dropdown lists show the available interpreters, ABIs, and platforms. Enable javascript to be able to filter the list of wheel files.

mol_hume-0.7.0-cp314-cp314-win_amd64.whl (667.2 kB view details)

Uploaded Sep 2, 2026 CPython 3.14Windows x86-64

mol_hume-0.7.0-cp314-cp314-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (535.5 kB view details)

Uploaded Sep 2, 2026 CPython 3.14manylinux: glibc 2.24+ x86-64manylinux: glibc 2.28+ x86-64

mol_hume-0.7.0-cp314-cp314-manylinux_2_24_aarch64.manylinux_2_28_aarch64.whl (498.6 kB view details)

Uploaded Sep 2, 2026 CPython 3.14manylinux: glibc 2.24+ ARM64manylinux: glibc 2.28+ ARM64

mol_hume-0.7.0-cp314-cp314-macosx_11_0_arm64.whl (459.9 kB view details)

Uploaded Sep 2, 2026 CPython 3.14macOS 11.0+ ARM64

mol_hume-0.7.0-cp314-cp314-macosx_10_15_x86_64.whl (505.2 kB view details)

Uploaded Sep 2, 2026 CPython 3.14macOS 10.15+ x86-64

mol_hume-0.7.0-cp313-cp313-win_amd64.whl (643.6 kB view details)

Uploaded Sep 2, 2026 CPython 3.13Windows x86-64

mol_hume-0.7.0-cp313-cp313-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (534.9 kB view details)

Uploaded Sep 2, 2026 CPython 3.13manylinux: glibc 2.24+ x86-64manylinux: glibc 2.28+ x86-64

mol_hume-0.7.0-cp313-cp313-manylinux_2_24_aarch64.manylinux_2_28_aarch64.whl (498.1 kB view details)

Uploaded Sep 2, 2026 CPython 3.13manylinux: glibc 2.24+ ARM64manylinux: glibc 2.28+ ARM64

mol_hume-0.7.0-cp313-cp313-macosx_11_0_arm64.whl (459.3 kB view details)

Uploaded Sep 2, 2026 CPython 3.13macOS 11.0+ ARM64

mol_hume-0.7.0-cp313-cp313-macosx_10_15_x86_64.whl (505.1 kB view details)

Uploaded Sep 2, 2026 CPython 3.13macOS 10.15+ x86-64

mol_hume-0.7.0-cp312-cp312-win_amd64.whl (643.5 kB view details)

Uploaded Sep 2, 2026 CPython 3.12Windows x86-64

mol_hume-0.7.0-cp312-cp312-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (534.9 kB view details)

Uploaded Sep 2, 2026 CPython 3.12manylinux: glibc 2.24+ x86-64manylinux: glibc 2.28+ x86-64

mol_hume-0.7.0-cp312-cp312-manylinux_2_24_aarch64.manylinux_2_28_aarch64.whl (498.1 kB view details)

Uploaded Sep 2, 2026 CPython 3.12manylinux: glibc 2.24+ ARM64manylinux: glibc 2.28+ ARM64

mol_hume-0.7.0-cp312-cp312-macosx_11_0_arm64.whl (459.3 kB view details)

Uploaded Sep 2, 2026 CPython 3.12macOS 11.0+ ARM64

mol_hume-0.7.0-cp312-cp312-macosx_10_15_x86_64.whl (505.0 kB view details)

Uploaded Sep 2, 2026 CPython 3.12macOS 10.15+ x86-64

mol_hume-0.7.0-cp311-cp311-win_amd64.whl (639.8 kB view details)

Uploaded Sep 2, 2026 CPython 3.11Windows x86-64

mol_hume-0.7.0-cp311-cp311-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (535.0 kB view details)

Uploaded Sep 2, 2026 CPython 3.11manylinux: glibc 2.24+ x86-64manylinux: glibc 2.28+ x86-64

mol_hume-0.7.0-cp311-cp311-manylinux_2_24_aarch64.manylinux_2_28_aarch64.whl (498.4 kB view details)

Uploaded Sep 2, 2026 CPython 3.11manylinux: glibc 2.24+ ARM64manylinux: glibc 2.28+ ARM64

mol_hume-0.7.0-cp311-cp311-macosx_11_0_arm64.whl (457.8 kB view details)

Uploaded Sep 2, 2026 CPython 3.11macOS 11.0+ ARM64

mol_hume-0.7.0-cp311-cp311-macosx_10_15_x86_64.whl (502.9 kB view details)

Uploaded Sep 2, 2026 CPython 3.11macOS 10.15+ x86-64

mol_hume-0.7.0-cp310-cp310-win_amd64.whl (639.2 kB view details)

Uploaded Sep 2, 2026 CPython 3.10Windows x86-64

mol_hume-0.7.0-cp310-cp310-manylinux_2_24_x86_64.manylinux_2_28_x86_64.whl (533.5 kB view details)

Uploaded Sep 2, 2026 CPython 3.10manylinux: glibc 2.24+ x86-64manylinux: glibc 2.28+ x86-64

mol_hume-0.7.0-cp310-cp310-manylinux_2_24_aarch64.manylinux_2_28_aarch64.whl (496.4 kB view details)

Uploaded Sep 2, 2026 CPython 3.10manylinux: glibc 2.24+ ARM64manylinux: glibc 2.28+ ARM64

mol_hume-0.7.0-cp310-cp310-macosx_11_0_arm64.whl (456.5 kB view details)

Uploaded Sep 2, 2026 CPython 3.10macOS 11.0+ ARM64

mol_hume-0.7.0-cp310-cp310-macosx_10_15_x86_64.whl (501.4 kB view details)

Uploaded Sep 2, 2026 CPython 3.10macOS 10.15+ x86-64

File details

Details for the file mol_hume-0.7.0.tar.gz.

File metadata

Download URL: mol_hume-0.7.0.tar.gz
Upload date: Sep 2, 2026
Size: 493.5 kB
Tags: Source
Uploaded using Trusted Publishing? Yes
Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for mol_hume-0.7.0.tar.gz
Algorithm	Hash digest
SHA256	`89d4f1a7b490bd676b7e8b2d8c080c19cc2beaf7e3fb6120b10835bf20831289`
MD5	`c038ca2b709b4b3aced6a6a4e4bf3807`
BLAKE2b-256	`8f1d4b26559dd877ea2b155068834eb411ff0f51f4be28d8a4bdda1fa07aa568`

Algorithm	Hash digest
SHA256	`68dfd28028f2456edaa28b513775cc4475bf9fb9edd6820e2dd6a669b7b83102`
MD5	`df601597d9da1a4c63ee6162710803f7`
BLAKE2b-256	`4ad86ab78968406aaa93250e437df295afc183bd4e72d926ee6636d687883b99`

Algorithm	Hash digest
SHA256	`d0bf090af14a80ff62ba050b234f6afeb13fd41043881b631c940c24ae42c529`
MD5	`45e834befa3e958888c2514537004be2`
BLAKE2b-256	`b068322d5fe822dd0b80d6f26be661ae801fdae76fece2723cad8fbd5dc1e214`

Algorithm	Hash digest
SHA256	`0db6ef95b79b882cc72b346fba9655d20e1f4a7e97aa05665a980593db6d22f6`
MD5	`64aaf0045442e87219de63ea0a99f18c`
BLAKE2b-256	`5976bbebf6dc8ab627abd0a296dea7870a713dad5a567d437dd4790eb6e1baa5`

Algorithm	Hash digest
SHA256	`3926b666c9f86bf636a9d9c84c50a773e36ec20468a1748430a804ae5751936e`
MD5	`39558a9cdef5e49e8a1c0cc9d82cc79c`
BLAKE2b-256	`ade17d71d4d513eca52a82ba33fbccbdd2988671aa6012e961183f07cead1dc1`

Algorithm	Hash digest
SHA256	`d70e0627fa2ad7eb464f17ea79203c8b5eaabc336efb1cb01285e1b203c15fb0`
MD5	`a066c9b42ebace73c0fc706b2c02f5e5`
BLAKE2b-256	`b030285732ea684999915fe5c645ccd5dd2ebb976a81d4b39c64da608d2f005f`

Algorithm	Hash digest
SHA256	`4f987d416a29c361bd8da65a1530f02ff098e9faf16b12a1b27e2a714233fe5d`
MD5	`3ebb03a0294fada88ba2e55a7cdafe78`
BLAKE2b-256	`979d8afd40448bda66807be9ad8743a2f388767f295c2143cd91460c97f2afa5`

Algorithm	Hash digest
SHA256	`68defc458faab52775edfc42c0d6295ff504f91c96212e2e3085551763c9bfb6`
MD5	`28588065cf4d87d531f4601b64cabcd3`
BLAKE2b-256	`538b485796f2a1f89837c4e0aebb55b762dfa0054dbf3290bca2da6560d365ab`

Algorithm	Hash digest
SHA256	`2ee5f9940aaffa40248636342085fe854e315a115ad85199a8caab0f51fc0424`
MD5	`7fc3ea846560dc97d414757405d9cc0d`
BLAKE2b-256	`8329250c6dded967e996307999f53bd7955aed6a06c50a7cacc3d79ee08603a9`

Algorithm	Hash digest
SHA256	`420567ff5088a341c463d7f0b7c448e47958a7a30cfb58a22714a13b49603556`
MD5	`267e22ae68505beef5a7de5c0ef3c6cd`
BLAKE2b-256	`c11cc7d945dcc4e4fae2e0a46f848c4f5c29bafe6fbf1f000ae199af954901a6`

Algorithm	Hash digest
SHA256	`3ebba1d1af6e8785c7481f4d07a27433eba390b098b38bed936b185569f8698a`
MD5	`0d3d3158971bb30b4de523df297691f1`
BLAKE2b-256	`67abf950c909e4561671b15b328cf61cf319dcf87200207bfc73317dfc61b554`

Algorithm	Hash digest
SHA256	`ccf9fe5e2b83fa9f5c124fd6054e79dd839dc4c0b608235f5790f0c2421289ce`
MD5	`766f6ab753677baa008ddb9f7e2fab12`
BLAKE2b-256	`65628784f0337df434b5de2c2e1294787c60c14c99369f3f11822295bffde4f0`

Algorithm	Hash digest
SHA256	`b94556b36b31dffc0b76a0df3d01c5b418476f1cfa17d8a4693751a60394c3fe`
MD5	`3307c9875119ae05ac71f361471f7883`
BLAKE2b-256	`675303071e7ffd20b14170b02b8eabd65a1bfa8b5cd61d3426a9bc5d98d4983f`

Algorithm	Hash digest
SHA256	`a6850b5d9b50e628cdac11275b3a4bd95cd5cbd4858353cbc625e461419ac85d`
MD5	`1e69c79afddd916e95a54b7483bd5731`
BLAKE2b-256	`d217293368742e46c5ff9c3db0413e3d4ce0e5f10d1a0b928856059124098a7c`

Algorithm	Hash digest
SHA256	`c5b0835179f08294919b5aad56d31ca9e7b32c8fb7d03609c61878f8c29af6ae`
MD5	`9829be5646c3488ed3193aabbb84b5fd`
BLAKE2b-256	`ae5248aac7341084b5ceb0151c317ae069a8ca5af472b5e5ed9ab38c254d9c8d`

Algorithm	Hash digest
SHA256	`b6acdd36ac34d5c58a4c3c23a0d9f07c4d7639eb21afa3bedac5de56386b39d3`
MD5	`c5f3ee0a72acf9f4b7aeae77809fa33c`
BLAKE2b-256	`4e87b8c715dd8cb4494cd96145678c3aa581224eee94482e1be93e52ab93e030`

Algorithm	Hash digest
SHA256	`356a261b405e6e5f1472d7c29bbb81f3d0ef085a85fa7b8ee5daebde7f770e4d`
MD5	`b161235f19cb0915084955ae3ace0114`
BLAKE2b-256	`7a0b8d6633d3032e11ebfa52ed684a3e5a41e78be0b6e6f587916ca43ffc3529`

Algorithm	Hash digest
SHA256	`36356fbfa596de0542b47747f440e66797f0e8889fdfc475d402429dabd15801`
MD5	`dc8ac8bd60ad55e4224900e2dd436246`
BLAKE2b-256	`0556f6bbcd4750a87b2e7c42b2c6c8f9be172a0855f2da210066fa5e182befaf`

Algorithm	Hash digest
SHA256	`c0b99673a350aaa3418b4f7f5d5a2e2fbda6abf6aa62b6a4d4c5c5803a206192`
MD5	`bedd31ddb8e5275a6376eaf51b7767ed`
BLAKE2b-256	`189460128568f67513ed1dd00cb6ce5d9d5b2a47fd1a7b7d54c0417071a2fae6`

Algorithm	Hash digest
SHA256	`287609978c9983222eb8cccbad7879e325c85d2c92653bcee11aef642391f8ae`
MD5	`d33c656c625cf9177a2b32658a0e1176`
BLAKE2b-256	`530c1c56b3c5f579621138479b73d30e810f5411a31522471a1ae01491088cec`

Algorithm	Hash digest
SHA256	`c6a74eecf90e25a52d655e292d216a058f00b49703c0a0e79bfa30d533132491`
MD5	`edd8c21ea1fe73c904d8094a3db028c9`
BLAKE2b-256	`0daa258b6bc20976cbf9556527a1276b9005751d03a93f90f00a0edb78f267b3`

mol-hume 0.7.0

mol-hume

Which columns

The one decision you have to make

Flags

What "verified" means

About that 285 us

The RDKit range

Why 1,269 and not 1,539

A reduced column set

What it costs, measured

Platforms

Values are not bit-identical across architectures

Development

Acknowledgments

License

Key dates

1 maintainer

Credits

License expression

Requires

Provides Extra

Tags

Classifiers

Download files

Source Distribution

Built Distributions

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

File metadata

File hashes

Provenance

File details

Algorithm	Hash digest
SHA256	`9a910ba5914bebb94c7afd855612f60e1b139bb66369693fcd9847581351c039`
MD5	`f87d97e0b978c1adefd681f7985401f3`
BLAKE2b-256	`206b1c1c006542408e2e0947e376ec93f6599af5eabc0853ac0fe58a0843b2d4`

Algorithm	Hash digest
SHA256	`3f7f5a1095c163f3febf64b0eaa6353ba59f34c30a77722a5ca7d95db2057c79`
MD5	`63f9aeb20a1442cd6c3dbde07991c946`
BLAKE2b-256	`5e61d513a7486b14d927e1dff7d07c19fb306066ec3165ce99e687e2676da85c`

Algorithm	Hash digest
SHA256	`8f4fe2e8af6344a33e6ba1c60d3561c1db28e9df43631bec50670e43357faff9`
MD5	`e61f2ee0c89f540fc92745c5be197a77`
BLAKE2b-256	`4d914fbf6b7e5d321a2c8e46887b1c94db6394d473e17166b2acbbb2f63a4293`

Algorithm	Hash digest
SHA256	`bc1b048c13266f00bd36df177878974e2f9e4182fd01426770078704c1180b78`
MD5	`2ea0f9e814ed0c7da88f9b3504646b17`
BLAKE2b-256	`462311571fb67ac7aca21000d3b1931c4e1245e937e089044f9f89402bd70a48`

Algorithm	Hash digest
SHA256	`b9000720fdaf443603c9e6ca3ed1d62b60421f739c505bbd83a916d7ff91d11b`
MD5	`0308761e60aaccf9cc7e704d12a98985`
BLAKE2b-256	`e359fd92c9a0df514491f26d282947dba55ddbb952e84fc5385b32fb6a078379`