At first glance, the S4TF seems (in general) to be a bit more verbose
Though I guess it comes from Swift’s way to name and construct things. It seems that the S4TF’s API doesn’t precisely match with TF for Python, right?
Sounds very reasonable. Probably as time goes we could build a kind of cheat-sheet between PyTorch/TF/S4TF/Keras/etc. to make the transfer between frameworks more simple. (Especially taking into account how fast the things change from one year to another).
Thank you @rxwei!
My goal was to show that PyTorch and S4TF are essentially a different name for the same thing.
As I’ve learned in this very course: syntax changes, but concepts last
To start, I’ve focused on the “Tensor” concept because is the very basic of any “matrix manipulation” framework.
AFAIK: PyTorch API is highly inspired to numpy to leverage “muscle memory” of numpy users… (such as numpy probably tried to leverage matlab users, but 0-based).
A SLICE OF THE SLICING HISTORY:
1968: Algol 68 -> a[:2, :2] # leading 2-by-2 submatrix "slice"
1970s: MATLAB -> A(1, :, 3) % single-dimension array along second dimension
Kenneth Iverson's APL (1957) had very flexible multi-dimensional array slicing, which contributed much to the language's expressive power and popularity.
The only thing I would change from the actual syntax is standardize the “..<” slicing operator, creating an “alias” with “:” (IE: A[:5] should be the same as A[..<5]).
Maybe @clattner can help us on that
I’ve two reasn for that:
PERSONAL REASON: I love Types because I’m a “distracted” person, having a “lott oF typo s” (a lot of typos) in all my code.
I’m pretty sure that thinking at A[:N] I’ll write a lot of times A[...N] in place of A[..<N]. This mistake is very dangerous because your code usually won’t break, but has a silent bug inside… (And Types can’t help me! For now ).
HORIZONTAL SPACE REASON: More characters for slicing (I’m joking of course )
I’ve got a “similar” experience in the past (more than 10 years ago) working on a project that required a lot of linear algebra. At the time my workflow was:
experimenting and prototyping with matlab: concise and comes with all math functions you need
once things works: port the “formulas” to plain STL/c++ (no option for fancy libraries, it was a 32MB “embedded” device…).
The big problem was that Matlab has 1-based arrays and c++ has 0-based. At the beginning I was sticking to the specific language convention (ie matlab code 1-based, c++ code 0-based), converting indices all the time and having a lot of bugs! Eventually I’ve written my own c++ PointsLibrary, overriding the operator and forcing it to be 1-based (pretending c++ to be matlab). This choice let me iterate way faster, with less bugs and “feeling more secure” coping and pasting formulas from one language to the other.
Coming back to my opinionated (not requested) opinion on that: I think that with a “:” like sintax we’ll reduce the number of bugs in porting existing code from python to swift.