Fast.ai and why Python is not the future of ML with Jeremy Howard

Re:Fast.ai and why Python is not the future of ML with Jerem... by nl on Tuesday September 08, 2020 @06:35PM (#24414393)

This sounds more like it's a new field.

I started looking for benchmarks (because it sounds like the kind of thing JAX would do well) and the very first link I clicked included:

Wraps for common C/Fortran methods like Sundials and Hairer's radau

which is exactly what was claimed wasn't needed.

[ Parent | on HN ]

Re:Fast.ai and why Python is not the future of ML with Jerem... by ChrisRackauckas on Wednesday September 09, 2020 @04:19AM (#24418651)

>I started looking for benchmarks (because it sounds like the kind of thing JAX would do well)

Currently Jax has an in-progress stiff ODE solver that's about 200x slower than SciPy

https://github.com/google/jax/issues/3686#issuecomment-65709...

and SciPy (with JIT) is about 50x-100x slower than the pure Julia methods

https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa...

so Jax has more than a little bit of a way to go.

[ Parent | on HN ]

Re:Fast.ai and why Python is not the future of ML with Jerem... by amkkma on Tuesday September 08, 2020 @08:27PM (#24415287)

Those aren't needed, but they are options. "he templated implementation allows arbitrary array and number types to be compatible, giving compatibility with arbitrary precision floating point numbers, GPU-based computations, unit-checked arithmetic, and other features. "

Those are exactly the things wrapping fortran and c won't give you

[ Parent | on HN ]