hi- thanks for the information. does this mean that Cint is "correct", or the compiler is "correct"? (or both/neither?) And is there anything I can do about it? 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