Wasn't there a Swift version of FastAI, too? Are they trying to have libraries in multiple ecosystems, or did that one peter out?
FastAI.jl: FastAI for Julia
11–20 of 24 posts
Re: FastAI.jl: FastAI for Julia
#12Wasn't there a Swift version of FastAI, too? Are they trying to have libraries in multiple ecosystems, or did that one peter out?
Swift for Tensorflow was cancelled.
Re: FastAI.jl: FastAI for Julia
#13Note: This is a sanctioned adaptation by members of the Julia community.
Re: FastAI.jl: FastAI for Julia
#14Wasn't there a Swift version of FastAI, too? Are they trying to have libraries in multiple ecosystems, or did that one peter out?
A bit of googling turns up [1][2], but [2] doesn't seem to have much recent activity (presumably in turn due to Google ceasing active development of S4TF [3]
[1] https://www.fast.ai/2019/03/06/fastai-swift/
Re: FastAI.jl: FastAI for Julia
#15This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
> Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented.
Yes, and? That is how a port is.
When FastAI for swift was a thing (is it still a thing?) it was (is?) using Swift For TensorFlow, not PyTorch. https://www.fast.ai/2019/03/06/fastai-swift/
Re: FastAI.jl: FastAI for Julia
#16This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
I’m not the main dev on FastAI.jl, but I work on the Julia ML community team that supported this project.
> Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented.
We are looking to offer a high level API for ML in Julia similar to fastai for PyTorch. The goal is to enrich the Flux ecosystem, so just calling into Python fastai wouldn’t be appropriate. FastAI.jl is built on top of several lower level packages that can be used separately from FastAI.jl. These packages help build out the ecosystem not just for FastAI.jl, but any ML framework or workflow in Julia.
> What does this mean for the development of fastai?
FastAI.jl is “unofficial” in that Jeremy and the fastai team did not develop it. But Jeremy knows about the project, and we have kept in touch with the fastai team for feedback. FastAI.jl doesn’t affect the development of Python fastai in any way.
> FastAI.jl has vision support but no text support yet.
> What is the timeline for FastAI.jl to achieve parity?
We’re working to add more out-of-the-box support for other learning tasks. Currently, we have tabular support on the way, but the timeline for text is not decided.
Note that the framework itself could already support a text learning method, but you’d have to implement the high level interface functions for it yourself. We just don’t have built-in defaults like vision. You can check out https://fluxml.ai/FastAI.jl/dev/docs/learning_methods.md.htm... for a bit more on what I mean.
> When should I choose FastAI.jl vs fastai?
It depends on what you need. PyTorch and fastai are more mature, but Julia and Flux tend to be more flexible to non-standard problems in my experience. If you’re interested, then give Julia/Flux/FastAI.jl a try. If we’re missing a mission critical feature for you, then please let us know so we can prioritize it.
Re: FastAI.jl: FastAI for Julia
#17This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
It does seem to actually be an unofficial implementation in Julia. So it shouldnt have any impact on the actual development? Im kinda wondering if Jeremy Howard has ok'ed using their name on a library that they're not in charge of? I didnt find a clear answer to that. Particularly troubling since it seems like the FluxML organization is behind this, not some random dude
Jeremy here. Yup I'm not just OK with the name and project, I'm thrilled with it! :) The Julia community is doing a fantastic job with this and I'm excited to see where it goes.
Something else to watch: Julia's brand-new compiler-based autodiff library, Diffractor. https://github.com/JuliaDiff/Diffractor.jl
Re: FastAI.jl: FastAI for Julia
#18This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
I’m not the main dev on FastAI.jl, but I work on the Julia ML community team that supported this project. > Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. We are looking to offer a high level API for ML in Julia similar to fastai for PyTorch. The goal is to enrich the Flux ecosystem, so just calling into Python fastai wouldn’t be appropriate. FastAI.jl is built on top of several lo…
Thanks. I use both fastai and Julia already (not together) so this is interesting to me.
I'm unlikely to adopt FastAI.jl at work anytime soon without a clear win over an existing tool.
Re: FastAI.jl: FastAI for Julia
#19This is interesting to me but the motivation behind this is unclear. Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. FastAI.jl has vision support but no text support yet. What does this mean for the development of fastai? What is the timeline for FastAI.jl to achieve parity? When should I choose FastAI.jl vs fastai?
I’m not the main dev on FastAI.jl, but I work on the Julia ML community team that supported this project. > Since FastAI.jl uses Flux, and not PyTorch, functionality has to be reimplemented. We are looking to offer a high level API for ML in Julia similar to fastai for PyTorch. The goal is to enrich the Flux ecosystem, so just calling into Python fastai wouldn’t be appropriate. FastAI.jl is built on top of several lo…
It is not surprising to me that there is no text support yet, given the issues of integrating 3D (batch x sequence x features) RNN support (for CUDNN). This issue has prevailed so long that I came to believe it is impossible to integrate with the current Flux.jl stack.
Re: FastAI.jl: FastAI for Julia
#20I think particular nice thing about this is that it is a bundle of nice libraries integrated together well, with nice docs.
Those libraries in turn also break down into other nice libraries and so forth (but many don't have does quite this nice) because that is how Julia is.
I can't seem myself ever using FastAI.jl (though I am sure many will). But I absolutely can see myself using Flux + FluxTraining.jl which nicely brings together TensorBoardLogger and EarlyStopping and several other things. (https://github.com/FluxML/FluxTraining.jl) And I can well imagine many will use DataLoaders.jl + Flux.
I feel like this project has nicely rounded out the ecosystem. Making standard tools where before there were a bunch of individual solutions per project. (Like I currently do use TensorBoardLogger + Flux directly with my own custom training loop)