On 6/27/2014 3:50 AM, Manu via Digitalmars-d wrote:
Totally agree.
Maintaining commitment to deprecated hardware which could be removed
from the silicone at any time is a bit of a problem looking forwards.
Regardless of the decision about whether overloads are created, at
very least, I'd suggest x64 should define real as double, since the
x87 is deprecated, and x64 ABI uses the SSE unit. It makes no sense at
all to use real under any general circumstances in x64 builds.
And aside from that, if you *think* you need real for precision, the
truth is, you probably have bigger problems.
Double already has massive precision. I find it's extremely rare to
have precision problems even with float under most normal usage
circumstances, assuming you are conscious of the relative magnitudes
of your terms.
That's a common perception of people who do not use the floating point unit for
numerical work, and whose main concern is speed instead of accuracy.
I've done numerical floating point work. Two common cases where such precision
matters:
1. numerical integration
2. inverting matrices
It's amazing how quickly precision gets overwhelmed and you get garbage answers.
For example, when inverting a matrix with doubles, the results are garbage for
larger than 14*14 matrices or so. There are techniques for dealing with this,
but they are complex and difficult to implement.
Increasing the precision is the most straightforward way to deal with it.
Note that the 80 bit precision comes from W.F. Kahan, and he's no fool when
dealing with these issues.
Another boring Boeing anecdote: calculators have around 10 digits of precision.
A colleague of mine was doing a multi-step calculation, and rounded each step to
2 decimal points. I told him he needed to keep the full 10 digits. He ridiculed
me - but his final answer was off by a factor of 2. He could not understand why,
and I'd explain, but he could never get how his 2 places past the decimal point
did not work.
Do you think engineers like that will ever understand the problems with double
precision, or have the remotest idea how to deal with them beyond increasing the
precision? I don't.
> I find it's extremely rare to have precision problems even with float under
most normal usage
> circumstances,
Then you aren't doing numerical work, because it happens right away.
