You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+60-92Lines changed: 60 additions & 92 deletions
Original file line number
Diff line number
Diff line change
@@ -97,129 +97,102 @@ A shorthand that creates the symbolic derivative program, simplifies it and inte
97
97
```
98
98
99
99
100
-
# WIP: The examples below are outdated and will be replaced soon using a new API
101
-
102
-
103
-
## Computing Jacobians
104
-
105
-
-- TODO: we can have vector/matrix/tensor codomains, but not pair codomains
106
-
-- until #68 is done;
107
-
-- perhaps a vector codomain example, with a 1000x3 Jacobian, would make sense?
108
-
-- 2 years later: actually, we can now have TKProduct codomains.
109
-
110
-
Now let's consider a function from 'R^n` to `R^m'. We don't want the gradient, but instead the Jacobian.
111
-
```hs
112
-
-- A function that goes from `R^3` to `R^2`.
113
-
foo :: RealFloat a => (a,a,a) -> (a,a)
114
-
foo (x,y,z) =
115
-
let w = x * sin y
116
-
in (atan2 z w, z * w)
117
-
```
118
-
TODO: show how the 2x3 Jacobian emerges from here
119
-
120
-
121
-
122
100
## Forall shapes and sizes
123
101
124
-
An additional feature of this library is a type system for tensor shape arithmetic. The following code is a part of convolutional neural network definition, for which horde-ad computes the gradient of a shape determined by the shape of input data and initial parameters. The compiler is able to infer a lot of tensor shapes, deriving them both from dynamic dimension arguments (the first two lines of parameters to the function) and from static type-level hints. Look at this beauty.
102
+
An additional feature of this library is a type system for tensor shape arithmetic. The following code is a part of convolutional neural network definition, for which horde-ad computes the gradient of a shape determined by the shape of input data and of initial parameters. The compiler is able to infer a lot of tensor shapes, deriving them both from dynamic dimension arguments (the first two lines of parameters to the function) and from static type-level hints. Look at this beauty.
in weightsReadout <>$ denseRelu + asColumnS biasesReadout
125
+
m1 = sreshape t2
126
+
denseLayer = weightsDense `smatmul2` str m1
127
+
+ str (sreplicate biasesDense)
128
+
in weightsReadout `smatmul2` reluS denseLayer
129
+
+ str (sreplicate biasesReadout)
152
130
```
153
131
But we don't just want the shapes in comments and in runtime expressions; we want them as a compiler-verified documentation in the form of the type signature of the function:
154
132
```hs
155
133
convMnistTwoS
156
-
:: forall kh kw h w c_in c_out n_hidden batch_size d r.
157
-
( 1 <= kh -- kernel height is large enough
158
-
, 1 <= kw -- kernel width is large enough
159
-
, ADModeAndNum d r ) -- differentiation mode and numeric type are known to the engine
160
-
=> -- The two boilerplate lines below tie type parameters to the corresponding
161
-
-- value parameters (built with SNat) denoting basic dimensions.
in file `MnistCnnShaped.hs` and the directory contains several other sample neural networks for MNIST digit classification. Among them are recurrent, convolutional and fully connected networks based on fully typed tensors (sizes of all dimensions are tracked in the types, as above) as well as weakly typed fully connected networks built with, respectively, matrices, vectors and raw scalars (working with scalars is the most flexible but slowest; all others have comparable performance on CPU).
158
+
in file `MnistCnnShaped2.hs` and the directory contains several other sample neural networks for MNIST digit classification. Among them are recurrent, convolutional and fully connected networks based on fully typed tensors (sizes of all dimensions are tracked in the types, as above) as well as their weakly typed variants that track only the ranks of tensors. It's possible to mix the two typing styles within one function signature and even within one shape description.
184
159
185
160
186
161
Compilation from source
187
162
-----------------------
188
163
189
-
Because we use [hmatrix] the OS needs libraries that on Ubuntu/Debian
190
-
are called libgsl0-dev, liblapack-dev and libatlas-base-dev.
191
-
See https://github.com/haskell-numerics/hmatrix/blob/master/INSTALL.md
192
-
for information about other OSes.
193
-
Other Haskell packages need their usual C library dependencies,
194
-
as well, e.g., package zlib needs C library zlib1g-dev.
164
+
The Haskell packages [we depend on](https://github.com/Mikolaj/horde-ad/blob/master/horde-ad.cabal) need their usual C library dependencies,
165
+
e.g., package zlib needs the C library zlib1g-dev or an equivalent.
166
+
At this time, we don't depend on any GPU hardware nor bindings.
195
167
196
168
For development, copying the included `cabal.project.local.development`
197
169
to `cabal.project.local` provides a sensible default to run `cabal build` with.
198
170
For extensive testing, a command like
199
171
200
-
cabal test minimalTest --enable-optimization -f test_seq
172
+
cabal test minimalTest --enable-optimization
201
173
202
-
ensures that the code is compiled with optimization and so executes the rather
203
-
computation-intensive testsuites in reasonable time.
174
+
ensures that the code is compiled with optimization and consequently
175
+
executes the rather computation-intensive testsuites in reasonable time.
204
176
205
177
206
178
Running tests
207
179
-------------
208
180
209
-
The test suite can run in parallel but, if so, the PP tests need to be disabled:
181
+
The `parallelTest` test suite consists of large tests and runs in parallel
210
182
211
-
cabal test simplifiedOnlyTest --enable-optimization --test-options='-p "!/PP/"'
183
+
cabal test parallelTest --enable-optimization
212
184
213
-
Parallel run may cause the extra printf messages coming from within the tests
214
-
to be out of order. To keep your screen tidy, simply redirect `stderr`,
215
-
e.g. via: `2>/dev/null`:
185
+
which is likely to cause the extra printf messages coming from within
186
+
the tests to be out of order. To keep your screen tidy, simply redirect
187
+
`stderr`, e.g.,
216
188
217
-
cabal test simplifiedOnlyTest --enable-optimization --test-options='-p "!/PP/"' 2>/dev/null
189
+
cabal test parallelTest --enable-optimization 2>/dev/null
218
190
219
-
You can also run the test suite sequentially and then all tests can be included
220
-
and the extra printf messages are displayed fine most of the time:
191
+
The remainder of the test suite is set up to run sequentially to simplify
192
+
automatic verication of results that may vary slightly depending on
193
+
execution order
221
194
222
-
cabal test simplifiedOnlyTest --enable-optimization -f test_seq
195
+
cabal test CAFlessTest --enable-optimization
223
196
224
197
225
198
Coding style
@@ -233,8 +206,8 @@ Spaces around arithmetic operators encouraged.
233
206
Generally, relax and try to stick to the style apparent in a file
234
207
you are editing. Put big formatting changes in separate commits.
235
208
236
-
Haddocks should be provided for all module headers and for all functions
237
-
and types, or at least main sections, from the most important modules.
209
+
Haddocks should be provided for all module headers and for the main
210
+
functions and types from the most important modules.
238
211
Apart of that, only particularly significant functions and types
239
212
are distinguished by having a haddock. If minor ones have comments,
240
213
they should not be haddocks and they are permitted to describe
@@ -245,11 +218,6 @@ of comments, unless too verbose.
245
218
Copyright
246
219
---------
247
220
248
-
Copyright 2023 Mikolaj Konarski, Well-Typed LLP and others (see git history)
221
+
Copyright 2023--2025 Mikolaj Konarski, Well-Typed LLP and others (see git history)
0 commit comments