文件列表:

Figures/ (0, 2021-10-31)
Figures/Makefile (17, 2021-10-31)
Figures/beaker.png (124045, 2021-10-31)
Figures/cuda-and-beaker.pdf (259223, 2021-10-31)
Figures/fft-bush2.dot (20016, 2021-10-31)
Figures/fft-lb4.dot (21156, 2021-10-31)
Figures/fft-lb5.dot (58636, 2021-10-31)
Figures/fft-rb4.dot (21148, 2021-10-31)
Figures/fft-rb5.dot (58626, 2021-10-31)
Figures/lsums-bush2.dot (3693, 2021-10-31)
Figures/lsums-lt4.dot (3198, 2021-10-31)
Figures/lsums-lt5.dot (6620, 2021-10-31)
Figures/lsums-lt6.dot (13873, 2021-10-31)
Figures/lsums-lt8.dot (59051, 2021-10-31)
Figures/lsums-lv16.dot (2356, 2021-10-31)
Figures/lsums-rt4.dot (3722, 2021-10-31)
Figures/lsums-rt5.dot (8690, 2021-10-31)
Figures/lsums-rt6.dot (20652, 2021-10-31)
Makefile (994, 2021-10-31)
cuda-scan.cuda (1095, 2021-10-31)
formatting.fmt (3094, 2021-10-31)
macros.tex (1243, 2021-10-31)
notes.md (5399, 2021-10-31)
src/ (0, 2021-10-31)
src/A.hs (512, 2021-10-31)
src/An.hs (545, 2021-10-31)
src/B.hs (495, 2021-10-31)
src/Bn.hs (577, 2021-10-31)
src/C.hs (794, 2021-10-31)
src/Cn.hs (819, 2021-10-31)
src/Dn.hs (842, 2021-10-31)
src/Fin.hs (506, 2021-10-31)
src/Misc.hs (365, 2021-10-31)
src/Trie.hs (1078, 2021-10-31)
tensor-liberated.lhs (16836, 2021-10-31)
unicode.tex (58, 2021-10-31)

## Can Tensor Programming Be Liberated from the Fortran Data Paradigm? Prepared for the [2021 Oxford Tensor Programming Seminar](https://www.cs.ox.ac.uk/seminars/2418.html). [Video](https://www.youtube.com/watch?v=oaIMMclGuog) [Slides](http://conal.net/talks/can-tensor-programming-be-liberated.pdf) Related paper (and video): [*Generic parallel functional programming: Scan and FFT*](http://conal.net/papers/generic-parallel-functional/) (ICFP 2017) ### Abstract Classic Fortran programs used "`GO TO`" for control and (multi-dimensional) arrays for data. While these unstructured building blocks suffice to encode implementations, they fail to yield clear understanding of the essential nature of algorithms and their correctness. Although "`GO TO`" has largely disappeared from modern programming, arrays are still widely embraced for parallel programming and machine learning. The resulting programming style suffers in safety and compositionality, leading to code that is unnecessarily difficult to write, read, prove, and reuse. The main message of this talk is that "array algorithms" are often not naturally array algorithms at all, but rather an error-prone, composition-resistant enmeshing of a safe, simple, and illuminating algorithm on a natural (non-array) data type, together with details of decoding from and encoding to arrays. By disentangling these natural data types and corresponding algorithms from their array encodings, we can gain deeper understanding of known algorithms and easily discover correct new algorithms, many of which are well-suited for the modern age of parallel hardware. Where desired, these clear, correct, and compositional algorithms can then be safely, correctly, and systematically (even automatically) converted to operate on arrays by applying a few simple principles in the form of well-known type isomorphisms. ### Video erratum Starting at 12:05 in [the video](https://www.youtube.com/watch?v=oaIMMclGuog), Jeremy conveyed a question about satisfying the key specification (commuting diagram) via degenerate `parseZ`. I'm afraid it was a bit early in the morning for me, and the answer I gave was rambling and incorrect. We really are searching for any `scanZ` that satisfies the specification, but we're *not* allowed arbitrary choices of `parseZ`. Rather, the parsing functions correspond naturally to the essential (non-array) `Z` type. Much later in the talk, I define all of these parsers parametrically. They're always isomorphisms for tries / Naperian functors (i.e., generalized, compositional, post-Fortran tensors). (They needn't isomorphisms for some non-Naperian functors, but even then they're semi-invertible and are defined naturally.)

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：