1,578 karma · joined November 22, 2009
https://imurray.bsky.social/
https://mastodon.social/@imurray / @imurray@mastodon.social
https://twitter.com/driainmurray
Research interests include statistics and machine learning.
Modules being removed [edit: in 3.13]: https://docs.python.org/dev/whatsnew/3.12.html#pending-remov...
Updating CGI scripts will be a bit fiddly: https://peps.python.org/pep-0594/#cgi
https://homepages.inf.ed.ac.uk/imurray2/code/mastodon.html
It's maybe easier to just use a separate app though, and avoid the faff of separate webpages entirely.
The main message is that if the knot is slightly loose, or messy, the strands pinch unevenly in a fall, and it can be really hard to untie (depending on the rope). Most of the video is experiments to show that. The knot only had to be slightly loose to cause problems.
The part that surprised me is that there are two different ways to tie the knot that basically look the same. They only differ in which of the two outgoing strands is the one that's loaded. They're both perfectly safe, but one can be a lot harder to untie than the other after a fall. I actually find it hard to end up with the "wrong" version of the knot, but I might just be lucky with what my muscle memory has latched on to. I certainly wasn't taught to watch out for the difference.
The difference between the two knots is shown at 13m 24s: https://www.youtube.com/watch?v=QAr-uHd8h8o#t=13m24s
His demo of one way to get the knot the right way around is at 7m 41s of another long video: https://www.youtube.com/watch?v=PJkCaUUhqgs#t=7m41s
Create isatty.so like this:
echo "int isatty(int fd) { return 1; }" | gcc -O2 -fpic -shared -ldl -o isatty.so -xc -
Then to make `some_program` think it's in a tty: LD_PRELOAD=./isatty.so some_programe
Source and more: https://unix.stackexchange.com/questions/249723/how-to-trick...Not with the standard library pickle, but "dill extends python’s pickle module for serializing and de-serializing python objects to the majority of the built-in python types".
I believe this juggle-dance routine https://vimeo.com/23958929 was put together using this tool. Neat use of prolog.
Radford Neal (2015) has an approach to computing sums exactly (to the correct rounded floating point number) in less than twice the time to do it naively. In some situations it can do work in parallel and saturate memory bandwidth, so takes roughly the same time: http://www.cs.toronto.edu/~radford/xsum.abstract.html
"Kahan’s (1965) method for reducing summation error (but without producing the exact result) was also tested on all systems. On modern 64-bit processors, computing the exact sum with the large superaccumulator method was faster than Kahan’s method for summations of more than about 1000 terms. Kahan’s method was significantly faster than the small superaccumulator method only for summations of less than about 100 terms."
I used atchange for a long time:
http://jeffreycopeland.com/work/PDF/1996-03-atchange.pdf http://users.fred.net/tds/lab/atchange.html
And now, out of habit, my own wrapper around inotify. But more polished solutions like entr do seem the place to start now.
At the British Juggling Convention I taught a workshop for absolute beginners to pass 5 clubs following http://passingpedagogy.com/ . Most of those who'd never picked up a club got on pretty well. Whereas some people who'd passed clubs in a different way were skeptical; you could tell their heart wasn't in it, and then unsurprisingly some of them didn't get it.
I do understand the resistance to going back to basics to fix things though. I can hoop (as in "hula-hoop") fairly well, and know some tricks. But I mostly hoop in one direction (counter-clockwise). If I try to do a trick clockwise, it's frustrating and I don't feel like carrying on, so I tend to give up, or go back to hooping counter-clockwise (fortunately one of my favorite tricks involves reversing the direction of the hoop). This weakness of mine was actually really useful (back when I still hooped with people). If I was showing someone else a trick, I could try it clockwise, which was an excellent reminder of how hard the trick really is, and to understand how/where it goes wrong.
I have a slight sour taste from the very end of the book, which discourages people from trying to go to higher numbers such as 5 balls. So after learning 3 balls, I set juggling aside. Much later, after meeting jugglers and seeing what people could do in videos online, I was inspired to learn a lot more... including 5 balls.
If you want people to excel, don't tell them they shouldn't expect to be able to do things, and that it's not worth the effort.
https://papers.nips.cc/paper/9383-integer-discrete-flows-and...
\usepackage{microtype}
in the preamble. The hyphenation would have been much nicer.https://web.archive.org/web/20080705135647/http://www.jmlg.o...
A small number of old NIPS (now NeurIPS) papers may even have used it.
This blog-post is from someone who prefers to do less mental arithmetic, but remember a few numbers: http://www.theexclusive.org/2012/08/converting-fahrenheit-in...
After a doc string put:
import docopt
args = docopt.docopt(__doc__, version='0.0.1')
Edit: krapht points out there is now support for multiple languages: https://github.com/docopthttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909818
(I've seen variants of this problem on Ubuntu 18.04 LTS.)
Sometimes the natural gradient turns out to be easier to compute than the gradient, and then it has made it in to applications.
Variational Inference: A Review for Statisticians (Blei et al., 2016) https://arxiv.org/abs/1601.00670
In this case, the gradient (51) has the Fisher Information in it and the natural gradient gets rid of that hard-to-compute term. This stuff has been used in a bunch of applications (section 5.1, p23).
You could argue that someone pragmatic might have tossed that positive definite term anyway (without knowing about natural gradients). Or come up with the same algorithm, as a heuristic improvement of existing algorithms. But the connection is quite neat.
Another example of links to natural gradients helping to make an algorithm cheaper: https://arxiv.org/abs/1712.01038 (Two related papers appeared at ICML 2018.)
(Please don't link to PDFs where a sensible parent html page exists. We can click from html to pdf but not vice-versa.)
That said, I wouldn't use Frixion pens to write in books that I wasn't prepared to write in using normal pens. The ink doesn't completely disappear. The color also comes back (to some extent) if you put the paper in a freezer.
Are you thinking of indefinite integrals? https://en.wikipedia.org/wiki/Risch_algorithm
This article is about a trick for definite integrals. If you can do the indefinite integral you can do a definite one, but not necessarily vice versa.
#define CSR_FLUSH_TO_ZERO (1 << 15)
unsigned csr = __builtin_ia32_stmxcsr();
csr |= CSR_FLUSH_TO_ZERO;
__builtin_ia32_ldmxcsr(csr);
from https://stackoverflow.com/a/8217313/ seems to work for me with gcc. I don't know how widely supported it would be.I was very surprised when I first learned that's not strictly true, because of denormal numbers[1]. Here's a session in ipython --pylab (with MKL), demonstrating a 200x slow-down for matrix multiplication with tiny numbers. Crazy!
In [1]: A = randn(1000, 1000)
In [2]: %timeit A @ A
25.9 ms ± 199 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
In [3]: A *= 1e-160
In [4]: %timeit A @ A
5.52 s ± 21.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
You hit denormal numbers more quickly with single-precision floats. I have been bitten by this issue in the wild a couple of times now, and seen a couple of other people with it too. Sometimes denormals are created internally in algorithms, when you didn't think your input matrices were that small.[1] https://en.wikipedia.org/wiki/Denormal_number#Performance_is...