well, the problem is I am using this calculation in a fit, so the relatively small error gets compounded over many iterations. When the difference is big enough, minuit ends up adjusting the fit parameters differently. so the real problem I have is that the fit converges to (very) different values, depending on whether I compile it or run it through Cint. I'd like to compile it (for speed) but I have to be able to trust the results, and it seems like the interpreted version is giving more reliable results. thanks- -s On Thu, 28 Jun 2001, Valeri Fine wrote: > 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