https://github.com/Functional-AutoDiff/STALINGRAD

sort by:
Revision Author Date Message Commit Date
8a78217 terminal newline 22 February 2018, 11:14:43 UTC
7df5281 .sc = Scheme 22 February 2018, 09:11:18 UTC
4032d37 update README.md 30 September 2016, 10:10:18 UTC
2092ecc add tools/README, direct unbuff users to /usr/bin/stdbuff 29 September 2016, 16:18:52 UTC
17b543a autogen.sh 29 September 2016, 16:18:52 UTC
d6abcbc update git ignorance 29 September 2016, 16:18:52 UTC
0a09aa6 remove qobischeme from autotools goo - in its own repo now 29 September 2016, 16:18:52 UTC
050b930 compile executable tools/sum 29 September 2016, 16:18:52 UTC
e9188e6 reduce warnings in mplayerwin.c 29 September 2016, 16:18:52 UTC
69e0b5f git ignore tools/ executables 29 September 2016, 16:18:52 UTC
d2106fb make mplayerwin and unbuff 29 September 2016, 16:18:52 UTC
7559fa1 mplayerwin.c from jeff via email 29 September 2016, 16:18:52 UTC
97ab4c9 autoupdate 29 September 2016, 16:18:52 UTC
ad5d137 Proper tangent solves the curried plus problem. 29 September 2016, 16:18:52 UTC
7b716f4 I should put my terrible hacks in properly. 29 September 2016, 16:18:52 UTC
004ac3a Standard options suggested by Jeff. 29 September 2016, 16:18:52 UTC
58d9d04 Another fun example to think about. 29 September 2016, 16:18:52 UTC
3b56dc1 A little abstraction to make running the benchmarks against DVL a little easier. 29 September 2016, 16:18:52 UTC
b946675 Raising to a given bundle level fixes DVL analysis errors on saddle.vlad. I am somewhat annoyed that it appeared to be necessary to do this in so many places; on the other hand, I am quite pleased that the DVL debugging facilities (such as they are) allowed me to identify the appropriate spots with relative ease. 29 September 2016, 16:18:52 UTC
226feb4 Now that I named this abstraction, I would use it. 29 September 2016, 16:18:52 UTC
a9ae899 Work around a limitation of DVL. This should not to affect Stalingrad's understanding of this program in the least. Yes, we need to come up with a real solution, but while the benchmark deadline looms I want to push quick hacks as far as they will go. 29 September 2016, 16:18:52 UTC
c9f5221 Oops, didn't mean to comment out all the tests. 29 September 2016, 16:18:52 UTC
b637121 Work around a known bug in DVL. Namely, that DVL doesn't like quoted lists with floating point numbers. 29 September 2016, 16:18:52 UTC
b206013 Specialize these polymorphic functions. This gives another 2.5x speedup on both examples (0.126 vs. 0.296 for the particle example and 0.08 vs. 0.216 for the saddle example). The total speedup compared with the original unoptimized version compiled without -O flag is 20x. 29 September 2016, 16:18:52 UTC
a1b5f90 Add top-level type signatures. I hate when they are omitted. 29 September 2016, 16:18:52 UTC
da44b5e Replace 'error "unimplemented"' with actual implementations. 29 September 2016, 16:18:52 UTC
202ed37 Don't need this extension anymore. Surprisingly, making arithmetic strict doesn't improve the performance (and sometimes make it worse). 29 September 2016, 16:18:52 UTC
bb11889 Don't need this bang pattern. 29 September 2016, 16:18:52 UTC
a18ab33 Replace explicit lambda with function composition. 29 September 2016, 16:18:52 UTC
a12bbe8 Oh, man. Replace 'foldl (+) 0' with 'sum'. 'foldl (+) 0' is leaky, the proper version is 'foldl' (+) 0' and it is called 'sum'. Speeds up the particle example by a factor of 2. 29 September 2016, 16:18:52 UTC
a3d72f9 Make 'lift' strict and inlinable. This seems to marginally speedup both programs. 29 September 2016, 16:18:52 UTC
62b9fc7 Make Bundle strict. This speeds up the particle example by a factor of 4. The saddle example becomes 20% faster. (For the saddle example, the difference between compiling the program with and without -O flag is more impressive: 0.277 vs. 1.649; for the particle example, this ratio is less than 2). 29 September 2016, 16:18:52 UTC
58dcffd Get rid of that n+1 pattern. 29 September 2016, 16:18:52 UTC
bdcfb0c The motivation for these stream experiments. 29 September 2016, 16:18:52 UTC
e4ca33a More thoughts about loop fusion. 29 September 2016, 16:18:52 UTC
25d9e6f Some commentary on variations on the theme. 29 September 2016, 16:18:52 UTC
642d38a Loop fusion. It seems to work. 29 September 2016, 16:18:52 UTC
b9bfc31 A little loop fusion experiment, just to check. 29 September 2016, 16:18:52 UTC
8ddf698 A file of random stuff where I was experimenting with Stalingrad's behavior. I don't actually know what to make of it. The latter examples observe that Stalingrad does not zero out constants in procedure bodies. 29 September 2016, 16:14:38 UTC
c22aad8 Updating the pointer to the BCL-AD implementations. 29 September 2016, 16:14:38 UTC
a8ef60c Ha! I discovered why this example fails in VL and DVL. 29 September 2016, 16:14:38 UTC
8c91603 Specifying order of evaluation. 29 September 2016, 16:14:38 UTC
d881478 Inserting an algebraic noop for the sake of the DVL type inference (which fails to unify a real with a bundle). 29 September 2016, 16:14:38 UTC
7e5c3f2 Tabs-B-Gone. 29 September 2016, 16:14:38 UTC
738df5d Sasha found a bug and convinced me that it was a real bug. Tests changed. 29 September 2016, 16:14:38 UTC
6067a14 That really needs to be sure and be a tab character. 29 September 2016, 16:14:38 UTC
84f4929 Trying to test confluence. Unfortunately, Stalingrad refuses (I think it doesn't like the constants in closure bodies) and SLAD fails. 29 September 2016, 16:14:38 UTC
a944691 Another VLAD implementation is now approximately online. 29 September 2016, 16:14:38 UTC
77d0fc8 Abstracting away the differences between SLAD and VL as VLAD implementations (my, how minor they are!) 29 September 2016, 16:14:38 UTC
ef02f95 Easier to comment these files out now. 29 September 2016, 16:14:38 UTC
9a49254 Poking at Stalingrad's ability (or lack thereof) to deal with derivatives of functions that emit structures, whose primal answers are known at analysis time. 29 September 2016, 16:14:38 UTC
99669f0 Another nice example of perturbations that should not be confused. 29 September 2016, 16:14:38 UTC
a4109ed Hm. I ran Stalingrad, and now it gets a different answer than it did before. What's going on? Did I mess something up by abstracting the gradient computations? Do different machines produce different answers? What's going on here? 29 September 2016, 16:14:38 UTC
885d6ea Unknown number of derivative levels. The compiler takes longer than 10 minutes on this on khazad-dum. Is it in an infinite loop? 29 September 2016, 16:14:38 UTC
fa89182 Nothing is gained and many CPU cycles are lost by running all the long-running tests to 50 minutes. I propose cutting them off at 10. 29 September 2016, 16:14:38 UTC
baeb6d5 If I want to actually test the compiler properly (as opposed to, say, the quality of the compiler's error messages), I should probably try and defeat the abstract analysis in the places where I expect it to be defeated. 29 September 2016, 16:14:38 UTC
eec95be Ran particle in SLAD again. I am very surprised -- am I confusing the perturbations in a different way now? 29 September 2016, 16:14:38 UTC
6e34cec I find myself wanting to do the test-preparation actions often enough that there should probably be a task for them. 29 September 2016, 16:14:38 UTC
fee36cb Simplify, relying on the automatic addition of structure-extraction code. 29 September 2016, 16:14:38 UTC
280e7d9 Fold the if into the cond. 29 September 2016, 16:14:38 UTC
d8200c1 Moving around and explaining the testing code that now does a better job with compiling tests that produce structured outputs. 29 September 2016, 16:14:38 UTC
ca299b6 I want those bogons to really stand out. 29 September 2016, 16:14:38 UTC
4ee8152 I need union-free *and* to actually force the program to compute the answer I'm looking for, instead of having the analysis assume it knows the answer. 29 September 2016, 16:14:38 UTC
a19d9c7 Trying to support booleans in a union-free manner. 29 September 2016, 16:14:38 UTC
e2300e1 Supporting booleans in the careful writing hack. 29 September 2016, 16:14:38 UTC
c993669 Right. I should get right the case where the original answer was multiform. 29 September 2016, 16:14:38 UTC
23709e5 Do not produce error messages when trying to inspect parsed but not specialized expectations. 29 September 2016, 16:14:38 UTC
4f53968 More precise reason for why a certain test is rejected. 29 September 2016, 16:14:38 UTC
4cfc2db Drafting a mechanism by which the compiler can be tested on examples that emit structured answers. The trick is that if I know the expected shape, I can write code into the testee program that will destructure exactly that shape and write the real numbers. 29 September 2016, 16:14:38 UTC
44ac913 Second-order derivative of function-returning-function. 29 September 2016, 16:14:38 UTC
63fda50 Another example with a data structure instead of a function. Right. I should remember that derivative-R expects the output to be the real numbers, so it doesn't apply to these new, funky examples. 29 September 2016, 16:14:38 UTC
07592c0 And its reverse-mode variant. 29 September 2016, 16:14:38 UTC
8492ddf Here's an example to test the universality of AD. 29 September 2016, 16:14:38 UTC
7eb4d2b Making sure that REAL? can deal with abstract reals. 29 September 2016, 16:14:38 UTC
5baac05 The executable is named "vl", not "run-vl". 29 September 2016, 16:14:38 UTC
6145b87 Now that SLAD and VL both implement (include "foo"), I don't need to detect "bad definitions" any more. 29 September 2016, 16:14:38 UTC
2df78cc If this is to remain a "fast" example, it should explicitly introduce imprecision (for example, for the benefit of implementations that do not support -imprecise-inexacts). 29 September 2016, 16:14:37 UTC
987cd86 Moving the type-testing examples out into their own file. The main purpose of this is to open out the multiform defining car and cdr without interfering with later definitions of car and cdr, so that I stop getting that annoying "bad definition" error. 29 September 2016, 16:14:37 UTC
5dd47aa Why am I even testing for quasiquote? 29 September 2016, 16:14:37 UTC
ab3eb87 Reverse-mode versions of all the basics. 29 September 2016, 16:14:37 UTC
5feadc1 Importing some basic examples from the SLAD sources. It seems that the last one tickles a form of perturbation confusion that does not occur in the other examples (at least not those that finish quickly). 29 September 2016, 16:14:37 UTC
cc409e1 The executable is now named slad, not run-slad. 29 September 2016, 16:14:37 UTC
59cd980 I think I want failure-summary to be the default output at the end of make rather than test-failures, to avoid cluttering the output with all the SLAD unbound variables. The real answer, though, is some sort of "expected failure" system, or to do a better job of pre-filtering the examples that SLAD will predictably fall down on. Is there a good way to do that in parallel instead of in the serial test suite preparation phase? 29 September 2016, 16:14:37 UTC
cd6009e tool/failure-summary is now grammatically correct when there are 0 unbound variable failures. 29 September 2016, 16:14:37 UTC
95cce02 Approximate equality of floating point results inside structured outputs too. 29 September 2016, 16:14:37 UTC
761e611 SLAD computed an answer for probabilistic prolog. 29 September 2016, 16:14:37 UTC
560c176 SLAD computed a different answer than the one I had there. I am concerned. 29 September 2016, 16:14:37 UTC
647bb94 SLAD computed another answer. 29 September 2016, 16:14:37 UTC
4fafb96 Hoisting derivative procedure constructions out of loops makes this code friendlier to expository interpreters. 29 September 2016, 16:14:37 UTC
281dc00 SLAD computed a candidate answer to probabilistic-lambda-calculus in forward mode (and, by extension, the same answer can be presumed for reverse mode). 29 September 2016, 16:14:37 UTC
f12b7f5 More informative failure reporting (accounts for yet another kind of out-of-resource crash, and for the possibility that the test suite may not have run to completion). 29 September 2016, 16:14:37 UTC
ef9a521 Test supervisor now detects another way in which its subprocess may report dying and marks it as such. 29 September 2016, 16:14:37 UTC
f2d5218 Slightly more pleasant error state reports while the suite is running. 29 September 2016, 16:14:37 UTC
5cc08f7 Noting that double-agent does not have variations. 29 September 2016, 16:14:37 UTC
2429e20 Abstracting the gradient-ascent method in probabilistic-prolog.vlad. 29 September 2016, 16:14:37 UTC
24cd59f Abstracting the derivative-taking strategy in probabilistic-lambda-calculus.vlad. 29 September 2016, 16:14:37 UTC
89ea368 Abstracting the gradient calculations in particle.vlad. 29 September 2016, 16:14:37 UTC
7c7e106 Refactored saddle.vlad to abstract over the different gradient-taking strategies. 29 September 2016, 16:14:37 UTC
223340c The multivariate-argmin in saddle.vlad is an instance of an iterated line search. 29 September 2016, 16:14:37 UTC
86b4353 Making following directions a little friendlier for interpreters (untested, since only hairy things follow directions nowadays). 29 September 2016, 16:14:37 UTC
back to top