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 <
pgilbert@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-bounces@r-project.org [mailto:r-devel-bounces@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.
TED@MERCHANTSERVICECORP.COM
CTO
Merchant Services Corp.
17665 Leslie st., unit 30
Newmarket , Ontario
L3Y 3E3

	[[alternative HTML version deleted]]

