| crux | minion | |
|---|---|---|
| 1 | 1 | |
| 0 | 22 | |
| - | - | |
| 0.0 | 8.9 | |
| over 2 years ago | about 1 month ago | |
| Cython | C++ | |
| - | Mozilla Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crux
-
Ask HN: Should I publish my research code?
Been there, done that. I published my doctoral research code [1] so that others could inspect, verify, replicate, extend, etc. YMMV, but the feedback I received from other researchers ranged from neutral to surprisingly positive (e.g. people using it in ways that pleasantly surprised me). But let me expand on my own experiences while developing that software, trying to figure out how to replicate the then-current state of the art.
At the time there were two widely used software packages for phylogenetic inference, PAUP* [2] and MrBayes [3]. The source code for MrBayes was available, and although at the time I had some pretty strong criticisms of the code structure, it was immensely valuable to my research, and I remain very grateful to its author for sharing the code. In contrast the PAUP* source was not available, and I struggled immensely to replicate some of its algorithms. As a case in point, I needed to compute the natural log of the gamma function with similar precision, but there was no documentation for how PAUP* did this. I eventually discovered that the PAUP* author had shared some of the low-level code with another project. Based on comments in that code I pulled the original references from the 60s literature and solved these problems that had plagued me for months in a matter of days. Now, from what I could see in that shared PAUP* code, I suspect that the PAUP* code is of very high quality. But the author significantly reduced his scientific impact by keeping the source to himself.
[1]: https://github.com/canonware/crux
minion
-
Ask HN: Should I publish my research code?
I've posted a huge amount of academic code (I've linked to a small number at the end). I think you should, but it won't help advance your career immediately. However, I still think it's better for science.
What is useful is if you can produce code people can build on and do their own cool stuff with -- then they will cite you. However, getting something to a state where it is tested for all reasonable inputs, has some basic docs, etc. is a hard untaking.
https://github.com/minion/minion (C++ constraint solver)
https://github.com/stacs-cp/demystify (Python puzzle solver)
https://github.com/peal/vole (Rust group theory solver)
What are some alternatives?
python-qubit-setup - All scripts for controlling the instruments and acquiring data in our qubit setup.
SuperConductor - A playout client for Windows/Linux/macOS that will let you control CasparCG Server, BMD ATEM, OBS Studio, vMix, OSC-compatible devices, HTTP (REST)-compatible devices, and more!
superconductor - A tool to simulate superconducting circuits, comparable to SPICE.
3d-reorganization-prostate-canc
cd4-histone-paper-code - Public release of most of the data analysis code for Lamere et. al. 2016
pyview - pyview contains all reusable and generic classes and functions that I used in my qubit data acquisition setup during my PhD thesis.
3d-reorganization-prostate-cancer - Code, analysis, and results for Hawley, Zhou, et al., Cancer Research, 2021.
demystify
vole - A GAP package for backtrack search in permutation groups with graphs