You will also get differences if you change optimization settings; even though the hardware and OS and development tools are the same. The issue there involves rounding error, particularly on intermediate results, and propagation of that error (depending on the nature of the calculations after the rounding has occurred). Unless you're compiling the instance of R you're comparing your C/C++ results against, so you can be certain both are using the same compiler optimization settings, I would be very surprised it you were able to obtain results identical to the least significant bit. If you're using a different algorithm than what the R code uses, it becomes almost impossible to get results identical to the last significant bit (unless both use very unusual algorithms that are not susceptible to rounding error in intermediate results).
For initialization, if your code makes assumptions about how variables/arrays are initialized, you have a number of options to ensure that they're initialized to whatever you want, both in C and in C++. My practice, for high performance number crunching, has been to be diligent in creating unit tests and then integration tests that exploit known mathematical properties of the math I am using (e.g. the eigensystem computed from a matrix has a suite of mathematical properties that can be used to test the correctness of the implementation that computes the eigensystem of a matrix of any particular type, so one can construct tests based on those properties and a driver that applies the test on a suitably large number of randomly constructed matrices with specified properties). But, given the fact that different algorithms for computing the same thing are guaranteed to have slightly different results because of rounding errors, I almost never test for strict equality but instead test that differences are all less than some tolerance defined prior to the tests (and which depend on the precision in which the calculations are done). This does not necessarily carry a cost WRT performance if one is careful in the design of the classes used and makes appropriate use of inline functions (and, if you're up to it, template metaprogramming). HTH Ted On Fri, Sep 10, 2010 at 10:07 AM, Paul Gilbert < pgilb...@bank-banque-canada.ca> wrote: > With fortran I have always managed to be able to get identical results > on the same computer with the same OS. You will have trouble if you > switch OS or hardware, or try the same hardware and OS with different > math libraries. All the real calculations need to be double, even > intermediate variables. Also, I've had trouble with arrays not being > initialized to double 0.0. If you initialize to single 0.0 the > straggling bits can cause differences. You also need to be careful about > conversion from integer to real, to do double conversion. I'm not sure > about C, but I would guess there are some of the same problems. > > Paul > > >-----Original Message----- > >From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- > >project.org] On Behalf Of Renaud Gaujoux > >Sent: September 10, 2010 6:47 AM > >To: r-devel@r-project.org > >Subject: [Rd] Non identical numerical results from R code vs C/C++ > code? > > > >Hi, > > > >suppose you have two versions of the same algorithm: one in pure R, the > >other one in C/C++ called via .Call(). > >Assuming there is no bug in the implementations (i.e. they both do the > >same thing), is there any well known reason why the C/C++ > implementation > >could return numerical results non identical to the one obtained from > >the pure R code? (e.g. could it be rounding errors? please explain.) > >Has anybody had a similar experience? > > > >By not identical, I mean very small differences (< 2.4 e-14), but > enough > >to have identical() returning FALSE. Maybe I should not bother, but I > >want to be sure where the differences come from, at least by mere > >curiosity. > > > >Briefly the R code perform multiple matrix product; the C code is an > >optimization of those specific products via custom for loops, where > >entries are not computed in the same order, etc... which improves both > >memory usage and speed. The result is theoretically the same. > > > >Thank you, > >Renaud > > > >-- > >Renaud Gaujoux > >Computational Biology - University of Cape Town > >South Africa > > > > > > > > > >### > >UNIVERSITY OF CAPE TOWN > > > >This e-mail is subject to the UCT ICT policies and e-mail disclaimer > >published on our website at > >http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from > >+27 21 650 4500. This e-mail is intended only for the person(s) to whom > >it is addressed. If the e-mail has reached you in error, please notify > >the author. If you are not the intended recipient of the e-mail you may > >not use, disclose, copy, redirect or print the content. If this e-mail > >is not related to the business of UCT it is sent by the sender in the > >sender's individual capacity. > > > >### > > > >______________________________________________ > >R-devel@r-project.org mailing list > >https://stat.ethz.ch/mailman/listinfo/r-devel > > ==================================================================================== > > La version française suit le texte anglais. > > > ------------------------------------------------------------------------------------ > > This email may contain privileged and/or confidential information, and the > Bank of > Canada does not waive any related rights. Any distribution, use, or copying > of this > email or the information it contains by other than the intended recipient > is > unauthorized. If you received this email in error please delete it > immediately from > your system and notify the sender promptly by email that you have done so. > > > ------------------------------------------------------------------------------------ > > Le présent courriel peut contenir de l'information privilégiée ou > confidentielle. > La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute > diffusion, > utilisation ou copie de ce courriel ou des renseignements qu'il contient > par une > personne autre que le ou les destinataires désignés est interdite. Si vous > recevez > ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans > délai à > l'expéditeur un message électronique pour l'aviser que vous avez éliminé de > votre > ordinateur toute copie du courriel reçu. > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- R.E.(Ted) Byers, Ph.D.,Ed.D. t...@merchantservicecorp.com CTO Merchant Services Corp. 17665 Leslie st., unit 30 Newmarket , Ontario L3Y 3E3 [[alternative HTML version deleted]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
