Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
update roadmap #52
Just some minor tweaks to the Readme and Roadmap, to make it slightly more accessible for new users/contributors. The only really substantive change is adding support for default graphs to the roadmap.
Let me know if you think these changes make sense @Arafatk! Also I would be happy to work on default graph support if you agree that that is worth having. (Technically that's necessary for the basic usage tutorial, and I think it's a pretty important convenience for new users)
@Arafatk I'm thinking an interface that's something like this below, making
var1 = Tensorflow::Variable.new([1, 2, 3], dtype: :int32) # assigns to the default graph
tf = Tensorflow::Coordinator.new # there is probably a better name for this singleton var1 = tf.variable([1, 2, 3], dtype: :int32)
Ruby blocks could also easily support assigning a default graph:
graph2 = Tensorflow::Graph.new graph2.as_default do var1 = Tensorflow::Variable.new([1, 2, 3], dtype: :int32) end
Note how they in the Python api for
This and even more so the
Thanks for the responses guys. Good point re: also supporting placeholder/constant/etc. I was thinking of a very similar implementation using a thread variable.
I'm not quite clear which of the two proposed interfaces you guys prefer and would love to get a temperature read.
Option A: Use constructors on Tensorflow classes
var1 = Tensorflow::Variable.new([1, 2, 3], dtype: :int32) placeholder = Tensorflow::Placeholder.new([2, 2])
Option B: Have an object with helper methods defined on it
tf = Tensorflow::Coordinator.new # there is probably a better name for this singleton var1 = tf.variable([1, 2, 3], dtype: :int32) placeholder = tf.placeholder([2, 2])
To me, Option A feels slightly more like what one might expect from standard Ruby, but Option B achieves closer similarity to the feel of the Python library, which seems important. Interestingly, Option B actually isn't that different from just creating a graph instance, so I'm starting to question how useful it would really be.
@geoffreylitt I also think Option A would look more familiar to Ruby'ers. If we're consistent in how we translate the python API to Ruby, users should more easy be able to understand the Ruby API. Option A could also be we written with convenience class-methods so we don't have to write
module CrazyTensorFlowCoordinator def self.variable(value, dtype: nil) Variable.new(value, dtype: dtype) end end
or whatever you think is the cleanest.