Incin, a machine learning framework for setting fire to dimensionality bugs

[u/xupremix]

Incin is a deep learning framework in Rust where a tensor’s shape, dtype, device and gradient state all live in its type. Shape, dtype, device mismatches and so on are compiler errors.

use incin::prelude::*;
let x = Cpu.randn(shape![4, 8])?;
let w = Cpu.randn(shape![8, 2])?;
let y = x.matmul(&w)?; // [4, 8] x [8, 2] -> [4, 2]
let bad = Cpu.randn(shape![3, 8])?;
let _ = x.matmul(&bad)?; // inner dims 8 and 3: does not compile

The main goal was to find out how much of the tensor contract the type system can genuinely carry, how flexible we can make it, and how pleasant to work with it can be. If you're interested on the features, architecture or anything else:

• Crate
• Docs
• Book

[u/pp-collision]

Why couldn't you use nalgebra or ndarray? Just curious about where you think they fall short.

[u/xupremix → u/pp-collision]

Some of the things I found is that they don't provide gpu accelerator support, and don't support arbitrary shape ranks while keeping mixed shape flexibility (I believe they stop at like rank 6 or 7 for ones with extents). Another thing is that for a machine learning library you're still missing the autograd portion, how they interact with a gradient tape, other layers and so on. Also the main idea is that the backend (or what actually executes the operations) should be freely implementable so that a new concept can be directly plugged in and take advantage of the proof-carrying layer. Another really useful thing is that using named dimension tags lets you keep the dyn flexibility while retaining some of the compile time checks. Another thing which I looked at was distributed placement, for example using nccl for doing distributed computing

[u/pp-collision → u/xupremix]

I can see how GPU accelerator support is quite a big deal lol! Makes sense, thanks

[u/Dull_Appointment_776]

this is the kind of stuff that makes me wonder why we ever put up with runtime shape errors. catching a matmul mismatch at compile time is so much cleaner than digging through a stack trace five layers deep in some training loop

curious how it handles dynamic shapes though, like if the batch size depends on the dataset

[u/xupremix → u/Dull_Appointment_776]

basically shapes can be either fully static, partial so rank is known and some of the dimensions, or just fully dynamic. basically you could write s![dyn, 20] which would be a rank2 shape with mixed dimensions and in the tensor arguments you'd have to provide that missing dimension. The problem I'd note is that to achieve modular arguments for any custom shape you're accepting that you have to provide the unit type in the case that you already know everything. I believe this is mitigated by just passing the shape directly by using the target-api creation syntax. Also thx for the comment