Leaf: Machine learning framework in Rust
github.com
Leaf: Machine learning framework in Rust
1–10 of 53 posts
Re: Leaf: Machine learning framework in Rust
#2Any recurrent layers?
Re: Leaf: Machine learning framework in Rust
#3I think Microsoft's approach with CNTK is far preferable to this. Rather than defining all the layers in Rust or C++ it uses a DSL to specify mathematical operations as a graph.
You can easily add new layer types, and recurrent connections are easy too - you just add a delay node.
Furthermore, since the configuration file format is fairly simple, it is possible to make GUI tools to visualise it and - in future - edit it.
Re: Leaf: Machine learning framework in Rust
#4I think Microsoft's approach with CNTK is far preferable to this. Rather than defining all the layers in Rust or C++ it uses a DSL to specify mathematical operations as a graph.
You can easily add new layer types, and recurrent connections are easy too - you just add a delay node.
Furthermore, since the configuration file format is fairly simple, it is possible to make GUI tools to visualise it and - in future - edit it.
Re: Leaf: Machine learning framework in Rust
#5can you give us example
how to use that ?
Re: Leaf: Machine learning framework in Rust
#6Its interesting to see "technical debt" become a more common term. Is there a rigid definition for it?
From the article: "Leaf is lean and tries to introduce minimal technical debt to your stack."
What exactly does that mean?
Re: Leaf: Machine learning framework in Rust
#7I think Microsoft's approach with CNTK is far preferable to this. Rather than defining all the layers in Rust or C++ it uses a DSL to specify mathematical operations as a graph. You can easily add new layer types, and recurrent connections are easy too - you just add a delay node. Furthermore, since the configuration file format is fairly simple, it is possible to make GUI tools to visualise it and - in future - edit…
A DSL based format has some advantages as it easy to get going with building networks. However you are then constrained by what the program that interprets/executes the DSL supports in terms of loading/saving data, solvers etc.. If you want to do something more dynamic e.g. AlphaGo then you have to go back to a "real" programming language anyway.
That's not to say that Leaf won't have a DSL at some point, but we will wait until the features of the layers are a bit more stabilized and we have more clearly mapped out what goals we have for a DSL.
Re: Leaf: Machine learning framework in Rust
#8Its interesting to see "technical debt" become a more common term. Is there a rigid definition for it? From the article: "Leaf is lean and tries to introduce minimal technical debt to your stack." What exactly does that mean?
Tightly coupled code is how I define tech debt
Re: Leaf: Machine learning framework in Rust
#9Its interesting to see "technical debt" become a more common term. Is there a rigid definition for it? From the article: "Leaf is lean and tries to introduce minimal technical debt to your stack." What exactly does that mean?
It's code that you write (typically quickly), that you know will need to be re-written at a later stage. It's debt that will need to paid at some stage in the future. You didn't do it right first time.
Technical debt typically arises because the code was poorly structured or the programmer used the wrong tools/libraries (from a longer-term perspective) or didn't abstract when she should have. The current obsession with MVPs has led to an increase in technical debt.
Re: Leaf: Machine learning framework in Rust
#10Its interesting to see "technical debt" become a more common term. Is there a rigid definition for it? From the article: "Leaf is lean and tries to introduce minimal technical debt to your stack." What exactly does that mean?
It's code that you write (typically quickly), that you know will need to be re-written at a later stage. It's debt that will need to paid at some stage in the future. You didn't do it right first time. Technical debt typically arises because the code was poorly structured or the programmer used the wrong tools/libraries (from a longer-term perspective) or didn't abstract when she should have. The current obsession wi…
it could be any kind of maintainance, I thought