The problem is that anything that gets into Wikipedia becomes ingrained in the Internet's collective mind, which then can't be changed.

Of course, no computer is a true Turing machine, since the memory is always limited, but our computers are a useful physical approximation of a Turing machine because a small program can compute using a large memory. The Z3 is not that type of a device at all.

As I said, this is possibly out-of-date information. If there is someone here from the neuroscience field, they can probably make a better comment.

I think it's great that this work is still going on, it may produce insights about functioning of nervous systems. But the difficulties are fierce, and we're making very slow and difficult progress in an immense unknown area.

If you want to actually have infinite-dimensional volumes, you can't just assign finite values to them in a simple way, or you will have contradictions such as a certain volume being completely covered by a union of things which have 0 volume. In infinite dimensions, you instead have various measures like the Gaussian measure. Feynman's path integrals are a kind of way to assign a value - called amplitude - to an infinite-dimensional manifold (a kind of "volume") of paths. But that takes us well to the side of the idea of the ratio between cube and inscribed figure volumes.

Imagine that you have something which depends on many variables (hundreds), and you're trying to predict its behavior based on your previous experience. There is a high chance that the next combination of variable values that you see will be in one of the corners of the many-dimensional cube, because that's where the volume is (the central part of the cube has negligible volume, as we said above). This means that every measurement is in effect an outlier along several dimensions, making predictions very difficult. This is part of the "curse of dimensionality" in statistics. I have seen some people with excellent understanding of mathematics trip themselves up in this area.

"Workers of the Soviet Union! Let us consolidate ourselves even more around the Communist Party and the Soviet Government, mobilize our forces and our creative energy for the great work of building a Communist society in our country! Long live the unbreakable union between Party, Government, and People!"

Since the original question was about computing the velocity of a car, and since I work in the automotive field, let's take a real example: you want to know the approximate position, acceleration, and velocity (linear and angular) of your car. Your inputs are driven wheel speed (noisy, affected by wheelspin), non-driven wheel speed (noisy), accelerometer output (inaccurate, only present for some axes), GPS position (updated occasionally, has errors), and steering angle (pretty accurate, can be put into a chassis dynamics model). Almost certainly, you would use a Kalman filter to estimate the state of the car. Naive approaches such as subtracting two wheel speed values to obtain acceleration will not work well.

My point is that we should remember that numerical algorithms are a developed field with a lot of knowledge, and we should take advantage of the proven approaches. Sometimes, programmers who are not specifically from the physics or numerical fields, and who need to perform some computation, reach for a very simple approach such as the rectangle-rule integrals, and get bad results.

I've seen naive numeric methods cause everything from jerky motion in video games to incorrect navigation data for cars.

Although it is true that you can approximate the average speed by taking an average of instantaneous speed measurements, that's usually a very bad way to do it in any real world situation. Numerical difference values are always noisier than the underlying quantity, sometimes to the point of being unusable, so of course if you can just read off the quantity you want directly (total difference over time), you should do that. But even if you can't, you should use a proper integration method instead of the calculus definition.

I have seen the Sum(f(x_i) * delta) calculation in a lot of real-world code. It has bad convergence properties, bad errors when the function has large derivatives, and bad performance when the data has noise. Some of the code I've seen produces garbage results, or has thousands of function evaluations when you need, like, four. "Quadrature? I think I heard that before, but I don't remember what it means."

In summary, please don't compute derivatives as (f(x_i+1)-f(x_i))/delta, or compute integrals as Sum(f(x_i) * delta), and especially, please don't do the first immediately followed by the second. Which also happens. Look up numerical methods instead.

This has been a public service announcement.

Any image enhancement technique, deep learning-based or not, can result in hallucination - you're producing information which was not in your input, which you're able to do because you have priors. But this can always result in incorrect information.

Oh, and some years later, a friend of mine in America was asked by a family in the USSR (which would not be the USSR much longer) to bring some package or item to their relatives, who lived in some other suburb of NYC. My friend asked for the address. "Don't remember right now, but you'll be able to find them: they have two cars!"