111–120 of 142 posts
Earlier quoted context omitted.
Still waiting for the day when import Glibc isn't a thing on Swift examples.
Well, you can help make it come sooner… wink
I already have my share of platforms I care about.
Earlier quoted context omitted.
I have just started hearing about Jax. But it seems to be a low level library that Tensorflow uses right ? The latest release of Tensorflow probability uses JAX under the hood. So what do you mean when you say you're moving to JAX versus Tensorflow
In your first sentence you're mistaking JAX and XLA XLA: Accelerated Linear Algebra, I guess it's kind of a backend/compiler that optimizes Linear Algebra/Deep Learning calculations with some very interesting techniques, among them fusing kernels JAX: In some sense syntax sugar over XLA, but a better way of describing it is Composable transformations + Numpy + some Scipy. The composable transformations allow you to t…
"TensorFlow Probability (TFP) is a library for probabilistic reasoning and statistical analysis that now works on JAX! For those not familiar, JAX is a library for accelerated numerical computing based on composable function transformations.
We have ported a lot of TFP's most useful functionality to JAX while preserving the abstractions and APIs that many TFP users are now comfortable with."
Tensorflow is migrating a bunch of stuff to JAX. Even they use the "library" word for their own porting. For a user like me, it looks like Jax is a library that tensorflow uses...but the end-user usable library is tensorflow.
Earlier quoted context omitted.
> There's nothing in Swift that's inherently suitable for ML The type system?
Speed, too. For PyTorch to train models and run inference quickly, your Python code gets translated to C++/CUDA. Part of the idea with S4TF is to be able to write ML code in a single, fast language.
I like Swift but looking at the code examples I got to say preparing data and setting up a model is 10x easier in Julia.
Who would want to use an Apple-centric language for ML, seriously? Apple hardware is outright incompatible to the kind of hardware we use daily in machine learning workstations.
>Who would want to use an Apple-centric language for ML, seriously? Apple hardware is outright incompatible Based on how you wrote your comment, I'm guessing you may not know this S4TF is a Google initiative. Yes, Chris Lattner used to work for Apple but he was at Google Brain during the start of this project. When his team wanted to create a language where automatic differentiation and gradient descent was a 1st-cla…
I really don't understand why they didn't go with Julia, it fits the purpose much better than Swift, already having a ML ecosystem and having great interop with Python, C, C++, R and Matlab. Heck JAX, where a lot of TF refugees are going, is pretty similar to Zygote
Related: Why Swift for TensorFlow: https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
Earlier quoted context omitted.
> There's nothing in Swift that's inherently suitable for ML The type system?
Speed, too. For PyTorch to train models and run inference quickly, your Python code gets translated to C++/CUDA. Part of the idea with S4TF is to be able to write ML code in a single, fast language.
S4TF still requires either c cuda kernels or XLA. Julia on the other hand has JIT GPU codegen and its CPU codegen has been benchmarked to beat openblas
Earlier quoted context omitted.
> It's difficult to find usages for autodiff I guess there are lots of uses in optimisation problems, and in sampling algorithms for statistics. I don't know how easy it will be to sell Swift to people who now use Stan or Stata (or R) and don't think of themselves as programmers. > In a language with extensible syntax(ex: proc macros), this would sit in a library. And this would allow easier iteration of different de…
Does autodiff exist in R? Then why not use R since it seems it also has much ML algo support due to its focus on statistics - its used by many statisticians. Is the idea here that Swift is a more approachable language and thus this is to lower the barrier of entry to TF?
You could write autodiff in say C++ but it is a user unfriendly language not well suited for machine learning and scientific computing.
Swift is a nicer high level language you can do autodiff in. But honestly I don’t see the point with Swift either.
Julia already does AutoDiff extremely well and outperforms Swift and pretty much everybody else.
Earlier quoted context omitted.
Does autodiff exist in R? Then why not use R since it seems it also has much ML algo support due to its focus on statistics - its used by many statisticians. Is the idea here that Swift is a more approachable language and thus this is to lower the barrier of entry to TF?
I think the main selling points of Swift to tensorflow are: * Speed, ML learning pipelines are often bottlenecked by the data load and transformation. TF had new mechanisms (the last I've seen was TF.data). But a language compiled to native is much more flexible in that regard. * Type safety. Sometimes issues with the models can pop long after they have been running. The hope is that typed API's will show simple erro…
Number types are first class which is a big part of it and you can add extra custom passes to the JIT compiler in regular library code.
Earlier quoted context omitted.
On HN circles maybe. https://juliacomputing.com/case-studies/
There's a difference between popular and "not a toy language." I'm not arguing Julia isn't used, I'm arguing it's not used often enough to be a merit irrespective of other reasons.