While approximate computation may be most readily used for processing data for human sensory input, it could also be useful for certain test-and-confirm type problems (where an approximate test--not even necessarily absolutely excluding false negatives--can filter out a majority of uninteresting results [distributed computing projects tend to work this way, the Large Hadron Collider also uses data filtering which _might_ be amenable to approximation if the false negative probability was sufficiently low]).
Something like a search engine could probably use approximate computation (the result is a list sorted by estimated fitness).
It might be possibly to increase the effectiveness of a safety system by allowing the use of more data and more processing even though the processing is approximate. Likewise, a self-correcting system (e.g., a flight control system) could tolerate minor errors.
Much simulation is effectively approximate (e.g., modelling of the gravity of distant objects as a single point object) already. In addition, measurements are inherently approximate and incomplete, so using approximate computation might be less inaccurate than one might naively expect.
Error detection and correction are also probabilistic, and so might be able to use approximate computation (Lyric Semiconductor's ECC product?).
This reminds me of college courses that described the notion of significant digits. If I take a measurement accuracy of 0.1 , and then mash a number data points together and apply statistical methods, my answer will never be more accurate 0.1 or even less. Computers are stupid with arithmetic and will give me 10 decimal points to the right. And then keep these answers and process all these digits to compute a new answer. Audio and video processing generate data that is interpreted by human analog processes that greatly smooth out the results. Sound is measured with a logarithmic scale. I defy anyone human to detect less than 1 dB of sound pressure. And computers measure millivolts, not dB. We can save a lot of data storage by compressing the raw data reducing the number of bits to manage.
This is very interesting. I think it will have an impact in power consumption of future devices. I don't mind a little less precision for the display or sound, but I hope it will still balance my checkbook correctly.
You may think that a financial/banking application would always require absolute precision at 32-bit or 64-bit resolution but......
....already some bodies like the U.K. tax are unlikely to bother about calculations to the last penny or pursue people who have got tax returns wrong in the pence column.
In many individual cases that may involve ignoring a relatively low-order significant digit in base 10. Obviously for company accounts the pence is a the least significant of much larger number of significant digits.
Nonetheless for a great number of calculations (just as on your calculator) there are a large number of leading zeros that we insist on adding together to get zero.
@Peter: You may think that a financial/banking application would always require absolute precision at 32-bit or 64-bit resolution but......
I thought that it was mandated by law that software used by financial institution return the EXACT same answers as if you performed the calculation using pencil and paper. And that it was for thsi reason that they still used a form of BCD (binary coded decimal) rather than binary-based floating point...
You may well be right in terms of financial computing.
But my point is that if I accidently make a miss-statement in my tax return in the pence column (which in my case will be quite a significant digit) i doubt that the Her Majesty's Revenue and Customs will come after me; not while they are chasing Google and the Duchy of Cornwall.
It is great to see this idea applied to processors!
This idea has applications even for scientific computing, albeit at the shared-memory/message-passing level. The book "Parallel and Distributed Computation: Numerical Methods" by Bertsekas and Tsitsiklis of MIT identifies asynchronous/partially-asynchronous parallel iterative algorithms that converge to correct solutions even if their intermediate results are not exchanged in timely fashion. One could go from there to partially-accurate intermediate results rather than non-timely intermediate results.
Way back in the mid-1990s, we exploited this to propose non-strict cache coherence/message passing for parallel processors, to speed up parallel programs (HiPC 1996: "Program-Level Control of Network Delay for Parallel Asynchronous Iterative Applications", http://dl.acm.org/citation.cfm?id=822137). Today that would help power savings as well! Later we looked at modern applications that leverage genetic algorithms, etc (ICPP 2000, ISCA WSHMM Workshop 1999, etc). Subsequent to our 1996 HiPC paper, folks at Georgia Tech and erstwhile DEC CRL applied the idea to parallel multimedia applications -- they built a system called Beehive I think.
It is great that the idea has now reached the processor level. I recall when I first talked about my version of the idea to a few colleagues in the mid-1990s. They looked at me like I didn't know the basics of science!
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.