Am Fri, 31 May 2013 07:02:11 +0530 schrieb Shriramana Sharma <samj...@gmail.com>:
> Thanks to all who replied. > > On Thu, May 30, 2013 at 10:07 PM, Diggory <digg...@googlemail.com> wrote: > > > > Since D does all operations at highest possible precision anyway (even for > > double or float) it only makes a difference when the value is being stored > > to memory and then read back again. > > But isn't this true for even C/C++ i.e. that the actual FP calculation > is done at a higher precision than what is exposed? And this is so > that rounding errors may be minimized? (I mean, I can see how repeated > multiplications and square roots and such would totally devalue the > LSBs of a double if calculations were done only in double precision.) Well more or less. When C was designed PCs didn't have 80-bit floating point (real). So the specification read like this: » All floating arithmetic in C is carried out in double-precision; whenever a float appears in an expression it is lengthened to double by zero-padding its fraction. « The C runtime achieves this by switching a FPU setting for internal precision from real - the default - to double. So in C, double * double will in deed NOT use the full FPU precision. Later specifications (~1998) allowed for greater precision in C just like D does it. But I imagine few C compilers actually do this since it breaks code and is platform specific. E.g. PowerPC has 128-bit as the maximum precision, so the same program running on x86 and PowerPC using the full precision might give different results! So to summarize, C typically gives you the same results across platforms, D encourages compiler implementers to use a higher precision. (http://dlang.org/float.html) > So IIUC the only thing D does newly is to actually *expose* the full > machine precision for those who want it? Well there is the switch for the internal FPU precision and there is data types (like real). Most C compilers *do* offer 'real' data types under the name 'long double' and you can also change the FPU precision with intrinsics or compiler switches. So if you really want it you can get the same precision in C as in D. But you have to specialize for different compilers. > But really how much use is > that? Because a friend of mine was warning (in general, not > particularly about D) against falling into the illusion of higher > precision == higher accuracy. If I use 80-bit FP as my data storage > type, then only if an even higher precision were actually used inside > the processor for calculations would the LSBs retain their > significance, right? It totally depends on the values and operations you apply on them. If you add two values which have the same exponent and their mantissas can be added without changing this exponent, you have 100% accuracy. If you do more complex arithmetics, accuracy is lost and your friend is right. But you seem to care so much about precision and not at all about speed or memory consumption that you will probably sleep better knowing that you might have saved one or two bits of precision from some calculations. :p > So in the end what is real useful for? For everything that's not stored. ;) Function returns and variables that the compiler will likely keep in a FPU register: real foo(real x, real y) { real z = x + y; return z; } (If you use float or double for variable z, the compiler is forced to insert instructions that will round down and store the FP value in memory just to load it back up into an FPU register for the return.) -- Marco
