i need to go out, so this is just off the top of my head, but isn't this really just some kind of efficient approximation? in which case (1) can it be extended to other problems trivially (so that we have an optimization library that we can 'plug in' to arbitrary numerical problems) and (2) how good is it at extrapolating?
the garmin data actually is in an open format. i've written software to decode it using publicly available documentation. the software is free to use. you can copy the (.FIT) file off the watch over USB.
if anyone is interested, i have a project that allows you to process and visualize data from garmin devices (FIT files in general). it includes a command (ch2 fit records <filename>) that dumps the contents of a file. it's not got many users and is a little unpolished still, but recently i added docker support which makes it easier to try out.
it's more than that. i cannot get to my (presumably clean, running linux, carefully maintained) home machine situated in chile, connecting from the uk.
what an awful diagram. it implies there's some kind of symmetry that relates all four, but when you look at the details there are asymmetries. if you think it was helpful look at it again and explain why di appears in two quarants but dq and dv appear once each.
You can rearrange the inductor equation to get di = (1/L) dϕ. Then the quadrants are perfectly symmetrical except for the ugly 1/L. But that's just an arbitrary unit created by humans, you could fix that by defining the unit of inductance as the inverse of what we use now.
you want mode, not median. there's no reason to think that the background is close to the median colour. that's kinda the whole point of the article...
(median works well if you have symmetrically distributed noise, which is true when denoising astronomy photos, for example, but not here).
I was thinking the same thing, but for sets of images where the occluding items are a relatively small percentage of the image area (and are moving around enough between frames), taking the median pixel value is effectively the same thing as the mode, but faster. (e.g. if you take 10 frames, the 1-2 frames where a pixel is occluded will almost certainly be an outlier to the 8-9 frames where the pixel is almost exactly the same, and the median will take the value in the middle of those 8-9 frames.
(Another problem with mode is that you'd have to posterize the image to ensure that shifting light, noise and camera movement don't cause the values of background pixels to vary slightly. Mode is much more brittle in that respect.)
If I recall correctly, Lightroom / Photoshop has a handy "median" filter, but no mode filter, which is why the popular method uses median.
i just wanted to say thanks to the truecrypt devs for a decade of largely unthanked and criticised work that, as far as i can tell, has been impressively reliable.
[kinda disappointed that, despite arriving so late to this thread, no-one seems to have said this.]
just want to second uml distilled. if you need to use uml you should read it - it's very slim and very practical. http://martinfowler.com/books/uml.html
also, uml with a tool like enterprise architect (which is basically a set of gui interfaces onto a database, where you construct a design in the database using the views, and are forced to be consistent) is very different from sketching a few diagrams.
it's not for me, but with a good tool you can see the attraction in certain scenarios.
