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.
@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 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.
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!
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.
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.