From: m_b_metcalf on 17 May 2010 06:29 On May 17, 12:20 pm, m_b_metcalf wrote:> On May 16, 9:07 pm, Thomas Koenig wrote: > > > > > > > Consider the following program: > > > program main > >   implicit none > >   real, dimension(1) :: a, b > >   real, dimension(1,1) :: aa, bb > >   a(1) = -1.0 > >   b(1) = 0.0 > >   print *,a(1)*b(1) > >   print *,dot_product(a,b) > >   aa(1,1) = -1.0 > >   bb(1,1) = 0.0 > >   print *,matmul(aa,bb) > > end program main > > > Assuming that the processor supports signed zeros, is the following > > result OK? > > >   -0.0000000 > >    0.0000000 > >    0.0000000 > > The standard states; "Processors that distinguish between positive and > negative zeros shall treat them as equivalent ... as actual arguments > to intrinsic functions other than SIGN ..." > > Thus, the result seems correct (and I haven't a clue what Robin is > wittering on about). > > Regards, > > Mike Metcalf- Hide quoted text - > > - Show quoted text - Sorry, I take back my comment (misread the -1.0 as -0.0). But I still don't understand Robin's remarks! From: Tobias Burnus on 17 May 2010 06:29 On 05/16/2010 09:07 PM, Thomas Koenig wrote:> Consider the following program: > a(1) = -1.0 > b(1) = 0.0 > print *,a(1)*b(1) > print *,dot_product(a,b) > aa(1,1) = -1.0 > bb(1,1) = 0.0 > print *,matmul(aa,bb) > Assuming that the processor supports signed zeros, is the following > result OK? Well, in terms of numerics, small deviations from the exact result can be expected (cf. [for instance] the Goldberg paper); in this case the deviation "(-0.0)-(0.0)" is zero and thus one can be happy. > -0.0000000 > 0.0000000 > 0.0000000 I think it also shows how the calculation is done; depending how the calculation is done, the sign is lost (e.g. "0 + (-0)" - should this be +0 or -0?). If intrinsic is inlined and not handled via a call to the run-time library, the chance is higher that the sign comes out as expected - as then the compiler can fold the implicit loops of dot_product and matmul into a simple multiplication and assignment. Using gfortran and g95, I get the -/+/+ result, with NAG f95 -/-/+ and with ifort (and the option "-assume minus0"!) I get -/-/-.* I think all variants in the output are standard conform and - for real-world code - one does something wrong if one worries about such deviations. Tobias * Several compilers have an option for handling negative zeros (gfortran: -fsign-zero); the option is needed not only for I/O but also and more importantly for the SIGN intrinsic as some Fortran 77 programs rely on a non-signed 0. From: FX on 17 May 2010 06:35 > | The result really is a zero with a minus sign, and not a> | very small negative number. > > You don't know that until you try what I suggested above. Well, the possibility of a compiler bug is not the question Thomas asked. He asked if a compiler giving this output would be considered standard-conforming. And also, I can argue that even after trying what you suggest, you still have no further information, because you could be experiencing a bug in the I/O library :) -- FX From: robin on 17 May 2010 07:35 "FX" wrote in message news:hsr64n\$107t\$1(a)nef.ens.fr... |> | The result really is a zero with a minus sign, and not a | > | very small negative number. | > | > You don't know that until you try what I suggested above. | | Well, the possibility of a compiler bug is not the question Thomas asked. He doesn't have to. It's a possibility. | He asked if a compiler giving this output would be considered | standard-conforming. I know what he asked. From: steve on 17 May 2010 13:03 On May 17, 3:29 am, Tobias Burnus wrote:> On 05/16/2010 09:07 PM, Thomas Koenig wrote: > > > Consider the following program: > >   a(1) = -1.0 > >   b(1) = 0.0 > >   print *,a(1)*b(1) > >   print *,dot_product(a,b) > >   aa(1,1) = -1.0 > >   bb(1,1) = 0.0 > >   print *,matmul(aa,bb) > > Assuming that the processor supports signed zeros, is the following > > result OK? > > Well, in terms of numerics, small deviations from the exact result can > be expected (cf. [for instance] the Goldberg paper); in this case the > deviation "(-0.0)-(0.0)" is zero and thus one can be happy. > > >   -0.0000000 > >    0.0000000 > >    0.0000000 > > I think it also shows how the calculation is done; depending how the > calculation is done, the sign is lost (e.g. "0 + (-0)" - should this be > +0 or -0?). If one follows IEEE 754, then this is well-defined: When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be + in all rounding direction modes except roundTowardNegative; in that mode, the sign of an exact zero sum (or difference) shall be -­. However, x+x = x-­(­-x) retains the same sign as x even when x is zero. -- steve