482 karma · joined September 24, 2011
300GB hardrive becomes 300 10^9 bytes or 3 10^10. 32GB or memory becomes 32 2^30, or 2^35.
No ambiguity at all, and if you're spending hundreds of dollars for hardware, you should at least be able to grasp exponentiation.
> That would basically mean potential acquisitions would become public knowledge
That would kind of be the point, it would be about fairness. People may not want to invest in a promising project that could change the world, just for it to be bought up by the next FB/Google.
So maybe that could be the deal going forward - sure I'll put up $100 to fund your project, but that comes at the cost of you not selling out in the future.
EDIT: Clearly the weight of your vote would be proportional to your investment.
My intuition is that patronage systems lead to undue influence. If Coke will fund your video series, they'll want something in return, usually advertisements. That then leads a subtle (or not) influence on the content.
I think the best way to avoid that ultimately is crowd funding on a more massive scale, i.e. 10s-100s of millions of dollar, but that comes with a whole bag of issues.
Who cares? Why do people always feel compelled to make this kind of comment?
This more or less depends on what kind of mathematician you're talking to. A mathematician working on Frames and signals almost certainly uses that language. But someone working in PDEs probably doesn't, even if the theory intersects a lot. It's probably a sign that there's nothing wrong with mathematicians and engineers sharing concepts :).
This is correct. So my comment "I think generally a better approach to AD is to redefine your differentiation", doesn't really apply to AD. Essentially, AD is about differentiating functions, not data.
Try the script at the end of this comment. Here's the output http://imgur.com/5948cW6
Notice that the 0-th one is just a gaussian. If you're interested, these things have traditionally been called HDAFs, I have a library to do this kind of thing https://bitbucket.org/nmaxwell/hdaf it may need more documentation. I don't mind if anyone provides constructive feedback on it.
The functionality you'd be interested in is hdaf.hdaf_periodic_samples, - you can convolve with that to low-pass filter, and use hertz_to_sigma to get the sigma parameter (from cutoff frequency).
import numpy, scipy.special
import matplotlib.pyplot as plt
x=numpy.linspace(-2,5,1000)
for n in [0,1,4,10]:
s=1 if n==0 else n
h=scipy.special.gammaincc(n+1,s*x**2)
plt.plot(x, h)
plt.savefig("filters")
EDIT: formatting.The problem then, is that that general functions have no (essential) bandlimit [1]. Remember that differentiation acts as a multiplication by a monomial, in the frequency domain [2]. Non-constant polynomials always eventually blow up away from 0, so in differentiating, you're multiplying a function by something that blows up, in the frequency domain. This means that, in the result, higher frequencies are going to dominate over lower frequencies, at a polynomial rate.
Let me be clear, the problem with numerical differentiation is not just that rounding errors accumulate, it's that differentiation is fundamentally unstable, and not something you want to apply to real-world data.
It depends very much on what your application is, however, I think generally a better approach to AD is to redefine your differentiation, by composing it with a low-pass filter. If designed properly, your low-pass filter will 'go to zero' faster (in the frequency-domain) than any polynomial, thus making this new operator bounded, and hence numerically more stable. It's not a panacea, but it begins to address the fundamental problem.
One example of such a filter is Gamma(n+1, n x^2)/Factorial[n], where Gamma is the incomplete gamma function [3].
In Python:
scipy.special.gammaincc(n+1,nx2) or mpmath.gammainc(n+1,nx2, regularized=True)
To see why this is a nice choice, notice item 2 in [4]. This filter is simply the product of exp(- x^2) (the Gaussian) multiplied by the first n-terms of the Taylor series of exp(+ x^2), (1/ the-Gaussian). Since this series converges unconditionally everywhere, as n-> +infinity, this filter converges to 1 for a fixed x (as you increase n), however, since it's still a gaussian times a polynomial, it always converges to 0 as you increase x, but fix n.
This is my area of research, so if anyone's interested I can give more details.
[1] https://en.wikipedia.org/wiki/Band-limit [2] https://en.wikipedia.org/wiki/Fourier_transform#Analysis_of_... [3] https://en.wikipedia.org/wiki/Incomplete_gamma_function [4] https://en.wikipedia.org/wiki/Incomplete_gamma_function#Spec...
> I would be interested in seeing the cost of a truly equivalent generic PC build. ("Truly" equivalent meaning no non-Xeon CPUs and other "almost as good" parts, something that's all too commonly done with Mac Pro comparisons.
I agree with that. We'll have to see.
Also, if your convolution kernel is short enough, you can beat an FFT. So, in 2D with an NxN image, an FFT filter will have a complexity of about (N^2 + N^2 Log N). If your kernel is KxK, then direct convolution will be (N^2 K^2), so you have to compare Log N with K^2. But keep in mind 1.) these are asymptotic complexities the coefficients matter 2.) K may or may not depend on N 3.) FFTs are may have larger memory requirements, although you may be able to get away with in-place FFTs, and you don't have to explicitly compute the FFT of the gaussian - you can work that out analytically (you should get another gaussian...).
Also, as someone pointed out, the gaussian is separable, so then the complexity of the direct convolution is (K N^2).
Anyway, what are FFT libraries like for iOS? I suppose with Apples policies, you can't compile FFTW for your App?
As far as I understand it, they use the motors for regenerative breaking, and the motors don't contain permanent magnets. Where permanent magnets would be used, they use more coils, and thus can vary the strength of the magnetic fields, much like your car's alternator. This is also how they forgo the need for a gear box.
http://www.reddit.com/r/startrek/comments/1nwzd6/ambient_war...
https://gnu.org/fry/happy-birthday-to-gnu.html
This man is a wonderful person.