tensorflow-thread.txt

Just to +1 and pile on:   :-)

I agree that Swift isn’t perfect here, but I think there is some progress and reason to be optimistic.  For example, there is now a new independent “swift numerics” library that is being developed that includes things like ShapedArray and other application independent numerics things.

I’m also thrilled to see the improvements in plotting, concurrency primitives etc.  As things continue, I think a major missing link is that we need to have some kind of structure to pull together a “batteries included” set of libraries and provide a community curation mechanism.  There are examples of this from other communities (e.g. Boost in the C++ world), but Swift has not evolved one yet.  I think that figuring this out will be key to getting to the next level of community involvement and providing a coherent product for users,

-Chris

On Jan 11, 2020, at 3:35 PM, 'Brennan Saeta' via Swift for TensorFlow <swift@tensorflow.org> wrote:

Thanks for reaching out Christian! I agree that this is a really important question to think about. One question we need to resolve is: should the fundamental NDArray currency type in Swift support heterogeneous hardware? While I think we all agree that the existing C++-TensorFlow-backed Tensor cannot meet the needs of mobile & edge deployments (something I think a lot about), I think we also need to assume that we need to support more than just CPUs*, as we see accelerators on almost all computing devices from mobile phones to big-iron in data centers. I'm optimistic that we'll be able to engineer a next-version of some such type soon (as a taste, check out the SwiftRT presentation from Ed Connel a little while back). As for how we can all combine forces and work together as a community, I think that would be fantastic, and ideas are definitely welcome! (This is why we have our open design meetings and run the project the way we do, but feedback is definitely welcome.)

All the best,
-Brennan

* Although we need to support CPUs extremely well.

On Sat, Jan 11, 2020 at 2:16 PM Cristian Garcia <cgarcia.e88@gmail.com> wrote:
Dan, thanks for the response!

I did talk to Richard about ShapedArray in the Swift forum, my thought was that it would be better if regular Swift users could use it without depending on Tensorflow. You could consider making it a separate project so the community can move in this direction and give it more relevance. I'd love to contribute what I did to a longer term project.

I think a Dataframe-esk project like Penguin will be limited without a ndarray library to stand on. Kind of inverting the pyramid again.

I know time and resources are limited, but its also apparent that big projects like numpy tend to have sponsors because of their importance and difficulty. Numfocus seems to be the group that sponsors numpy and a couple of other projects.

On Sat, Jan 11, 2020, 13:29 Dan Zheng <danielzheng@google.com> wrote:
Hi Cristian,

Thanks for sharing your concerns about the Swift data science ecosystem!

Its well known that on a ML project most of the time is spent on data engineering which mostly involves the lower parts of the pyramid. Swift is in a very odd place where via S4TF its getting the advanced stuff perfect but has poor support for the basic stuff.

That's a fair point. There's some recent work from our team regarding higher-level ecosystem "building blocks", like a model input pipeline library, a Pandas-inspired dataframe library, and a low-level parallel programming library. The last two were presented at the last Swift for TensorFlow design review and the first will be presented at the next design review.

I don't know the history of numpy/scipy very well but I believe that if Google (and Apple?) really wants to push Swift forward it needs to focus on the building blocks.

That's fair, though I don't believe effort from companies alone isn't sufficient for creating and maintaining a Swift ecosystem. Realistically, teams all have limited bandwidth and differing goals: Swift for TensorFlow needs to support some internal use cases and benchmarking, for example.

I think a good direction for the ecosystem is for contributors to unify efforts. For example, https://github.com/apple/swift-numerics is a great project unifying numerical computing efforts in Swift. As another example, did you consider extending `ShapedArray` or `Tensor` from https://github.com/tensorflow/swift-apis rather than implementing a new NDArray library? Collaborating to standardize APIs and naming conventions while supporting multiple backends seems like a positive direction for the ecosystem!

Dan

On Sat, Jan 11, 2020 at 9:57 AM Cristian Garcia <cgarcia.e88@gmail.com> wrote:
I love S4TF, its very refreshing, principled, with tons of potential. But its great weakness has nothing to do with the S4TF itself: its the Swift ecosystem.

The natural pyramid for a Data Science ecosystem seems to be:

ndarray-lib > dataframe-lib > ml-libs

Its well known that on a ML project most of the time is spent on data engineering which mostly involves the lower parts of the pyramid. Swift is in a very odd place where via S4TF its getting the advanced stuff perfect but has poor support for the basic stuff.

Using the python bridge is a bit risky in my opinion because if you need to use a lambda e.g. in a df.map you are out of luck. Also, I believe you are bound to the GIL again (but don't take my word on it) which is one of the reasons to use Swift in the first place.

I created a library called NDArray for Swift and got it to a POC state, but this is titanic task and my spare time alone would not be enough to create a high quality product.

I don't know the history of numpy/scipy very well but I believe that if Google (and Apple?) really wants to push Swift forward it needs to focus on the building blocks. I hope this feedback doesn't sound like I am being mean, its just the honest thoughts of someone who wants to use this technology and see it succeed but can't in its current state.

--
To unsubscribe from this group and stop receiving emails from it, send an email to swift+unsubscribe@tensorflow.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to swift+unsubscribe@tensorflow.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to swift+unsubscribe@tensorflow.org.