Re: [ROOT] RE:Re: Differences between compiled and CIN

From: Valeri Fine (fine@bnl.gov)
Date: Thu Jun 28 2001 - 20:09:41 MEST


Hello 

You wrote:
> > In theory, E should match F. But they are different in very
> > high precision. 

  What did mean "match"? One would say you are not correct. 

  Myself  would say:

  In numerical calculation theory the difference between E and F must
 be less then the  IEEE double floating number representation precision. 
 That is about  A*1.E-16

  That theory has nothing to do with any compiler rather with the computer 
  hardware.
 
> thanks for the information.  does this mean that Cint is "correct", or the
> compiler is "correct"?  (or both/neither?).

   Both are correct. unless they show the relative precision of the results more then 1.0E-16

>  And is there anything I can do about it?
 
  You did not tell us what is your real problem.

  With my best regards, Valeri


> thanks-
> 
> 
> -s
> 
> 
> 
> 
> 
> On Thu, 28 Jun 2001, Masaharu Goto wrote:
> 
> > Hello all,
> >
> > Thank you for clarifying the problem.
> >
> > It turned out this is an inevitable error. The error occurs
> > in following context. In a compiled code,
> >
> >    double A = 31.123456898234981234;
> >    double B = 1.2341598123835981235;
> >    double C = 0.2353198723982591827;
> >    double D = A+B;
> >    double E = D+C;
> >    double F = A+B+C;
> >
> > In theory, E should match F. But they are different in very
> > high precision.  I guess compiler does something smart for
> > A+B+C and the result is different from D+C.
> > Cint is an interperter. It always calculates complex math as
> > D=A+B, E=D+C.
> >
> > I tried this using g++.  Other compiler may show different
> > results.
> >
> > Thank you
> > Masaharu Goto
> >
> >
> > >
> > >Hi Stefan,
> > >
> > >We are currently investigating this problem apparently due to some
> > >rounding convention. What we have seen so far is that the expression
> > >  double myerfSig = 1.0 - TMath::Erf( (valueErr*valueErr*par[1]*par[1] -
> > >                      value*par[0])/sqrt2/valueErr/par[1]/par[0] );
> > >is computed to be 0 with CINT and 1.3986208025063007199e-17 with the compiler
> > .
> > >This discrepancy generates obviously more discrepancies in the following
> > >expressions.
> > >For Masa: I assume that you are now dealing with this problem.
> > >
> > >Rene Brun
> > >
> > >
> >
> 
> 



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:50 MET