GIgilad·Feb 5, 2020Submission
Thinc (Python): Functional take on deep learning, compatible with your libraries
2 points · Open discussionexplosion
thinc
Python2017–2023
explosion / thinc
thinc
🔮 A refreshing functional take on deep learning, compatible with your favorite libraries
6Distinct people
11Mentions
0Explicit recommenders
2.9KGitHub stars
What to know before exploring
What it is
🔮 A refreshing functional take on deep learning, compatible with your favorite libraries
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year11 dated mentions
Observed mentions: 2017-10-05 22:49:58 UTC to 2023-09-29 06:35:55 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
3 sourcesThe best answer is, "with some difficulty". I've written a bit about the struggles here: https://thinc.ai/docs/usage-type-checking#model-types
There are basically two approaches, TypeVar and overload. You probably want TyepVar if you have exactly that sort of situations, but there's a lot about type vars I still don't understand, and the docs say almost nothing. The problem is the responsibility is kind of split in two places: the Python typing module doesn't really take any responsibility for usage, and mypy sees it as not mypy-specific, so neither describes it very well.
Our current solution is to avoid being fully variadic in the tensor type, and instead have a limited number of subclasses. This allows us to get by with overload, because we can enumerate out the set of argument-to-return mappings. This is especially important for the n
Read the rest
umpy API where you often have to overload on the types and values of other arguments, e.g. if you pass axis=(0, 1), you'll get a different rank of tensor back than if you had written axis=-1.
You can see the gory details of how I've done the numpy types here: https://github.com/explosion/thinc/blob/master/thinc/types.p...
You can write custom CUDA kernels, and I've written a few to support operations over our ragged format. Actually Thinc makes it pretty easy to optimise a specific bit of code with a custom op...cupy's fused decorator can also work well in some situations.
What you don't get is the compile-time auto-optimisation. Like, there's no asynchronous dispatch like you would get from PyTorch.
If you write a chunk of operations as just cupy maths, and then write the same thing in PyTorch and use the PyTorch wrapper, you can expect the PyTorch one to perform better. You would also need to write the backprop callback for the cupy maths you did. Sometimes you might find optimisations PyTorch doesn't though, especially around speed vs memory trade-offs.
Part of the philosophy and difference between this and other frameworks is that we do not do any comp
Read the rest
ilation or trickery of any sort: what you write is what gets executed. Obviously this is slower a lot of the time, but it means we can play well with others --- we're not wrestling for control of more of the graph so we can make more optimisations, and we're not limiting the hand optimisations you can do for custom situations.
Here's an example of how I've wrapped CUDA kernels, using Cupy's RawKernel feature. Most people do these as strings within Python source, but I find that super ugly. I like to keep the cuda source in .cu files, and then read in the file to compile it.
* The CUDA kernels: https://github.com/explosion/thinc/blob/master/thinc/backend...
* The code that calls cupy.RawKernel and the wrapping functions: https://github.com/explosion/thinc/blob/master/thinc/backend...
* The wrappers are called by the CupyOps object: https://github.com/explosion/thinc/blob/master/thinc/backend... . This object has the same API across backends, with some functions redefined with backend-specific implementations. In the NumpyOps object, I instead call into custom Cython code.
My CUDA skills aren't great, so I'm sure there are improvements that could be made. I'd welcome suggestions if anyone has them.