
TensorFlow for R - martgnz
https://github.com/rstudio/tensorflow
======
cs702
Great news for R users who largely have been left behind by the deep learning
community.

The main downside to this is that we will now start seeing all sorts of
experimental models from R users who know a lot more about statistics than
about software engineering and therefore often write code that is not very
elegant nor easy to understand.[1]

[1] Don't take it from me. Quoting Hadley Wickham: "Much of the R code you’ll
see in the wild is written in haste to solve a pressing problem. As a result,
code is not very elegant, fast, or easy to understand. Most users do not
revise their code to address these shortcomings. Compared to other programming
languages, the R community tends to be more focussed on results instead of
processes. Knowledge of software engineering best practices is patchy."
[http://adv-r.had.co.nz/Introduction.html](http://adv-r.had.co.nz/Introduction.html)

~~~
RA_Fisher
Surely we're better off if statisticians and software engineers work together.
That we're worse off when the two groups come together doesn't seem probable
...

~~~
cs702
Of course. Overall this is good news.

------
baldfat
This is a big leap for Machine Learning in R. R keeps moving forward in so
many ways. We now have native dplyr into Spark and now a TensorFlow library
from RStudio.

~~~
blahi
"Leap" is quite the exaggeration IMO, especially talking about ML. This is
improvement wrt to neural networks which had some support in R already
(mxnet). In ML, in general, R is quite a bit ahead of the competition.

You have been able to use dplyr on spark dataframes for a while now (at least
a year).

~~~
baldfat
> You have been able to use dplyr on spark dataframes for a while now (at
> least a year)

How? I didn't get it to work till sparklyr????

[https://blog.rstudio.org/2016/09/27/sparklyr-r-interface-
for...](https://blog.rstudio.org/2016/09/27/sparklyr-r-interface-for-apache-
spark/)

~~~
blahi
[https://github.com/RevolutionAnalytics/dplyr-
spark](https://github.com/RevolutionAnalytics/dplyr-spark)

~~~
baldfat
> not yet endowed with a through test suite. Nonetheless we expect it to
> inherit much of its correctness, scalability and robustness from its main
> dependencies, dplyr and spark.

> we don't recommend production use yet

I was a bit disappointed by that package, though it is great to see it in the
ecco-system of R.

The RStudio sparklyr is 100% native and Production ready. You should check it
out I was happily surprised.

------
RockyMcNuts
Where's TensorFlow for Excel?

~~~
max_
[http://www.deepexcel.net](http://www.deepexcel.net)

~~~
Houshalter
That's hilarious, but it doesn't use tensorflow. They seem to actually
implement a neural net in spreadsheet cells with formulas for every neuron.
That is insanely impractical and will be a million times slower and harder to
use than tensorflow.

~~~
kgwgk
Probably the spreadsheet they used for the demo when this software was
presented on April 1st, 2016 is still calculating...

------
dandermotj
This is awesome - been waiting for it for ages! But bindings to the python API
and not C++?

~~~
sja
I imagine that they did this in order to be able to use more of (or all of)
the TensorFlow functionality available in the Python API without having to
rewrite a huge amount of code in R.

There are Operations in TensorFlow that don't invoke the C++ layer directly.
Instead, they are composed of other Operations in Python, meaning that binding
directly to the C++ layer would require finding and rewriting that code.

It still gets sent down to the C++ layer at the end of it, though the stack
traces might end up looking pretty ridiculous.

