[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
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
On 10/09/2010 6:46 AM, Renaud Gaujoux wrote: 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? R often uses extended reals (80 bit floating point values on Intel chips) for intermediate values. C compilers may or may not do that. 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. Changing the order of operations will often affect rounding. For example, suppose epsilon is the smallest number such that 1 + epsilon is not equal to 1. Then 1 + (epsilon/2) + (epsilon/2) will evaluate to either 1 or 1 + epsilon, depending on the order of computing the additions. Duncan Murdoch Thank you, Renaud __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
Thank you Duncan for your reply. Currently I am using 'double' for the computations. What type should I use for extended real in my intermediate computations? The result will still be 'double' anyway right? On 10/09/2010 13:00, Duncan Murdoch wrote: On 10/09/2010 6:46 AM, Renaud Gaujoux wrote: 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? R often uses extended reals (80 bit floating point values on Intel chips) for intermediate values. C compilers may or may not do that. 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. Changing the order of operations will often affect rounding. For example, suppose epsilon is the smallest number such that 1 + epsilon is not equal to 1. Then 1 + (epsilon/2) + (epsilon/2) will evaluate to either 1 or 1 + epsilon, depending on the order of computing the additions. Duncan Murdoch Thank you, Renaud ### 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
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
On 10/09/2010 7:07 AM, Renaud Gaujoux wrote: Thank you Duncan for your reply. Currently I am using 'double' for the computations. What type should I use for extended real in my intermediate computations? I think it depends on compiler details. On some compilers "long double" will get it, but I don't think there's a standard type that works on all compilers. (In fact, the 80 bit type on Intel chips isn't necessarily supported on other hardware.) R defines LDOUBLE in its header files and it is probably best to use that if you want to duplicate R results. The result will still be 'double' anyway right? Yes, you do need to return type double. Duncan Murdoch On 10/09/2010 13:00, Duncan Murdoch wrote: On 10/09/2010 6:46 AM, Renaud Gaujoux wrote: 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? R often uses extended reals (80 bit floating point values on Intel chips) for intermediate values. C compilers may or may not do that. 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. Changing the order of operations will often affect rounding. For example, suppose epsilon is the smallest number such that 1 + epsilon is not equal to 1. Then 1 + (epsilon/2) + (epsilon/2) will evaluate to either 1 or 1 + epsilon, depending on the order of computing the additions. Duncan Murdoch Thank you, Renaud ### 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
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
On Fri, Sep 10, 2010 at 11:46 AM, Renaud Gaujoux wrote: > 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. I've had almost exactly this situation recently with an algorithm I first implemented in R and then in C. Guess what the problem was? Yes, a bug in the C code. At first I thought everything was okay because the returned values were close-ish, and I thought 'oh, rounding error', but I wasn't happy about that. So I dug a bit deeper. This is worth doing even if you are sure there no bugs in the C code (remember: there's always one more bug). First, construct a minimal dataset so you can demonstrate the problem with a manageable size of matrix. I went down to 7 data points. Then get the C to print out its inputs. Identical, and as expected? Good. Now debug intermediate calculations, printing or saving from C and checking they are the same as the intermediate calculations from R. If possible, try returning intermediate calculations in C and checking identical() with R intermediates. Eventually you will find out where the first diverge - and this is the important bit. It's no use just knowing the final answers come out different, it's likely your answer has a sensitive dependence on initial conditions. You need to track down when the first bits are different. Or it could be rounding error... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
Ok. I quickly tried using LDOUBLE wherever I could, but it did not changed the results. I might try harder... I agree with you Barry, and I will re-double re-check my code. Thank you both for your help. Bests, Renaud On 10/09/2010 13:24, Barry Rowlingson wrote: On Fri, Sep 10, 2010 at 11:46 AM, Renaud Gaujoux wrote: 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. I've had almost exactly this situation recently with an algorithm I first implemented in R and then in C. Guess what the problem was? Yes, a bug in the C code. At first I thought everything was okay because the returned values were close-ish, and I thought 'oh, rounding error', but I wasn't happy about that. So I dug a bit deeper. This is worth doing even if you are sure there no bugs in the C code (remember: there's always one more bug). First, construct a minimal dataset so you can demonstrate the problem with a manageable size of matrix. I went down to 7 data points. Then get the C to print out its inputs. Identical, and as expected? Good. Now debug intermediate calculations, printing or saving from C and checking they are the same as the intermediate calculations from R. If possible, try returning intermediate calculations in C and checking identical() with R intermediates. Eventually you will find out where the first diverge - and this is the important bit. It's no use just knowing the final answers come out different, it's likely your answer has a sensitive dependence on initial conditions. You need to track down when the first bits are different. Or it could be rounding error... Barry ### 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
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
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
Re: [Rd] Development environment for R extentions on Windows
On Wed, Sep 8, 2010 at 6:39 PM, Duncan Murdoch wrote: > On 08/09/2010 5:37 PM, Jeffrey Horner wrote: >> >> On Wed, Sep 8, 2010 at 1:01 PM, Jeffrey Horner >> wrote: >>> >>> On Wed, Sep 8, 2010 at 12:37 PM, Duncan Murdoch >>> wrote: On 08/09/2010 1:21 PM, Jeffrey Horner wrote: > > Hi all, > > I'm setting up a development environment on Windows as the subject > implies. I've downloaded and installed Rtools211.exe (will upgrade > later when necessary) and I've also downloaded and installed mingw > with the help of mingw-get.exe. > > I come from a UNIX development background, so I'm at the bash shell > prompt for just about every step in R extenstion development. Question > is what is an appropriate environment for Windows development. What > shell do you use? Do you use cmd.exe with the PATH variable set up by > Rtools? Do you use the sh.exe that comes with Rtools? I've found the > bash shell from MinGW to be a pretty close equivalent to bash on UNIX. > Do you use something else? > I've used the bash shell in Cygwin for quite a few years, but I've been planning a switch to MSYS sometime. Cygwin seems to have made some bad decisions lately that make it harder and harder to work with. >>> >>> This is great news! I don't know how I could survive without bash's vi >>> style editing and command completion... >>> >>> Here's my PATH variable which sets the Rtools paths first, then MinGW: >>> >>> horn...@hornerj-win ~ >>> $ echo $PATH >>> >>> /c/Rtools/bin:/c/Rtools/perl/bin:/c/Rtools/MinGW/bin:/c/localbin:/mingw/bin:/bin:/usr/bin:/usr/lo >>> cal/bin:/c/Program Files (x86)/R/R-2.11.1/bin:/c/Program Files >>> (x86)/CollabNet/Subversion Client: >>> >>> /c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1. >>> 0/:/c/Program Files (x86)/MiKTeX 2.8/miktex/bin >>> >>> I'm going to follow the "R Installation ..." manual to compile R on >>> Windows and learn a bit about the build process. From there, I intend >>> to "port" some open source libraries that have support for being >>> compiled with MS VC++ over to MinGW. >> >> From the MinGW bash shell, the R build went quite smoothly. However, I >> did run into trouble with temporary files. I got around it by >> specifying TMPDIR like so: >> >> $ cd R_HOME/src/gnuwin32 >> $ TMPDIR=. /c/Rtools/bin/make all > > I don't know if anything would go wrong, but I'd avoid putting your temp dir > into the source tree. On my home machine I normally set R_USER to a > Windows-style path (with backslashes), and that seems to work. On my work > machine I think I set TMPDIR explicitly, but I forget what value I used. > >> >> If I didn't set TMPDIR, it would default to /tmp and the failure would >> occur within the mkR target of R_HOME/share/make/basepkg.mk. For >> reasons beyond me, the shell environment that's entered within the mkR >> target has no notion of a root directory. Anyone else seen this? > > I'm not sure you're using the write make procedure. Are you running make > from within src/gnuwin32, so you get the Makefile there? It shouldn't try > to use /tmp (but things might have changed recently). I was (see above), and I think I've found the culprit. R_HOME/share/make/basepkg.mk is utilized by both the UNIX and Windows build, and its target mkR will expand the shell variable f to a suitable path under /tmp if TMPDIR is not set. Rtools' shell (forked by make) has no notion of a root file system at /, so /tmp is never found. The solution is to, of course, always set TMPDIR to a suitable directory before invoking make. Surprisingly, setting TMPDIR=/tmp actually works since make expands it to the user's temporary folder. On my windows laptop, that's: /cygdrive/c/Users/hornerj/AppData/Local/Temp Jeff > > Duncan Murdoch > >> >> Jeff >> >>> Aside from my PATH variable, are there other things about my >>> development environment I should be aware of? >>> >>> Jeff >>> >> >> >> > > -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
Thanks Paul for the hints.
After some tests, reducing portion of my code, I found that simply doing
a naive computation of 'crossprod' in C does NOT give exactly the same
results as calling the Fortran underlying routine (dsyrk) as used in the
R source code.
I will try the double 0.0 to see if it makes a difference.
What do you mean by
"You also need to be careful about
conversion from integer to real, to do double conversion."
?
Where are the trap in this type of conversion?
Thanks.
Renaud
On 10/09/2010 16:07, Paul Gilbert 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 ...{{dropped:27}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
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. > > > >### > > > >
[Rd] A couple of typos in ?pairwise.t.test
Hi all,
After my reply on R-Help to the relevant thread, I noted what appear to be a
couple of typos in the Details section of ?pairwise.t.test. Note text with '**'.
Current text:
The **pool.SD** switch calculates a common SD for all groups and **used** that
for all comparisons (this can be useful if some groups are small). This method
does not actually call t.test, so extra arguments are ignored. Pooling does not
generalize to paired tests so **pool.SD** and paired cannot both be TRUE.
Proposed new text:
The **pool.sd** switch calculates a common SD for all groups and **uses** that
for all comparisons (this can be useful if some groups are small). This method
does not actually call t.test, so extra arguments are ignored. Pooling does not
generalize to paired tests so **pool.sd** and paired cannot both be TRUE.
If that is acceptable, a text file with a patch against the main svn trunk
version of pairwise.t.test.Rd is attached.
Regards,
Marc Schwartz
--- pairwise.t.test.Rd 2008-04-06 10:46:45.0 -0500
+++ pairwise.t.test.Rd.NEW 2010-09-10 10:16:53.0 -0500
@@ -27,11 +27,11 @@
\code{"greater"} or \code{"less"}. }
\item{\dots}{ additional arguments to pass to \code{t.test}. }
}
-\details{ The \code{pool.SD} switch calculates a common SD for all
- groups and used that for all comparisons (this can be useful if some
+\details{ The \code{pool.sd} switch calculates a common SD for all
+ groups and uses that for all comparisons (this can be useful if some
groups are small). This method does not actually call \code{t.test},
so extra arguments are ignored. Pooling does not generalize to paired tests
- so \code{pool.SD} and \code{paired} cannot both be \code{TRUE}.
+ so \code{pool.sd} and \code{paired} cannot both be \code{TRUE}.
Only the lower triangle of the matrix of possible comparisons is being
calculated, so setting \code{alternative} to anything other than
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A couple of typos in ?pairwise.t.test
On Sep 10, 2010, at 17:21 , Marc Schwartz wrote: > Hi all, > > After my reply on R-Help to the relevant thread, I noted what appear to be a > couple of typos in the Details section of ?pairwise.t.test. Note text with > '**'. > > Current text: > > The **pool.SD** switch calculates a common SD for all groups and **used** > that for all comparisons (this can be useful if some groups are small). This > method does not actually call t.test, so extra arguments are ignored. Pooling > does not generalize to paired tests so **pool.SD** and paired cannot both be > TRUE. > > > Proposed new text: > > The **pool.sd** switch calculates a common SD for all groups and **uses** > that for all comparisons (this can be useful if some groups are small). This > method does not actually call t.test, so extra arguments are ignored. Pooling > does not generalize to paired tests so **pool.sd** and paired cannot both be > TRUE. > > > If that is acceptable, a text file with a patch against the main svn trunk > version of pairwise.t.test.Rd is attached. Consider it done... Thanks. -pd > > Regards, > > Marc Schwartz > > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
On Fri, 10 Sep 2010, Duncan Murdoch wrote: On 10/09/2010 7:07 AM, Renaud Gaujoux wrote: Thank you Duncan for your reply. Currently I am using 'double' for the computations. What type should I use for extended real in my intermediate computations? I think it depends on compiler details. On some compilers "long double" will get it, but I don't think there's a standard type that works on all compilers. (In fact, the 80 bit type on Intel chips isn't necessarily supported on other hardware.) R defines LDOUBLE in its header files and it is probably best to use that if you want to duplicate R results. As a little more detail, 'long double' is in the C99 standard and seems to be fairly widely implemented, so code using it is likely to compile. The Standard, as usual, doesn't define exactly what type it is, and permits it to be a synonym for 'double', so you may not get any extra precision. On Intel chips it is likely to be the 80-bit type, but the Sparc architecture doesn't have any larger hardware type. Radford Neal has recently reported much slower results on Solaris with long double, consistent with Wikipedia's statement that long double is sometimes a software-implemented 128-bit type on these systems. The result will still be 'double' anyway right? Yes, you do need to return type double. Duncan Murdoch On 10/09/2010 13:00, Duncan Murdoch wrote: On 10/09/2010 6:46 AM, Renaud Gaujoux wrote: 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? R often uses extended reals (80 bit floating point values on Intel chips) for intermediate values. C compilers may or may not do that. 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. Changing the order of operations will often affect rounding. For example, suppose epsilon is the smallest number such that 1 + epsilon is not equal to 1. Then 1 + (epsilon/2) + (epsilon/2) will evaluate to either 1 or 1 + epsilon, depending on the order of computing the additions. Duncan Murdoch Thank you, Renaud ### 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 Thomas Lumley Professor of Biostatistics University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [xts, quantmod] segfault probelm when I work with memcpy function
Hi,
I work with SEXP C code and with xts and quantmod packages. I try to
touch how xts internal works.
So we have R session and:
> ls()
character(0)
> getSymbols('AAPL') # quantmod package
[1] "AAPL"
> ls()
[1] "AAPL"
> str(AAPL)
An ‘xts’ object from 2007-01-03 to 2010-09-09 containing:
Data: num [1:929, 1:6] 86.3 84 85.8 86 86.5 ...
- attr(*, "dimnames")=List of 2
..$ : NULL
..$ : chr [1:6] "AAPL.Open" "AAPL.High" "AAPL.Low" "AAPL.Close" ...
Indexed by objects of class: [Date] TZ:
xts Attributes:
List of 2
$ src: chr "yahoo"
$ updated: POSIXct[1:1], format: "2010-09-10 18:42:10"
> tail(AAPL,5)
AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume AAPL.Adjusted
2010-09-02251.26252.17 248.57 252.1714811900252.17
2010-09-03255.09258.78 254.50 258.7718580100258.77
2010-09-07256.64259.53 256.25 257.8112234200257.81
2010-09-08259.78264.39 259.10 262.9218777000262.92
2010-09-09265.04266.52 262.92 263.0715642700263.07
>
> q()
Save workspace image? [y/n/c]: y
[dan...@entropy ~]$
It's looks, that xts data in mamory looks like this (Open=o,High=h,Low=l etc):
o(...)oh(...)hl(...)lc(...)cv(...)va(...)a
So if I want to read Open price I need to read this array (from C
code) from x[0] to x[nrow(x)-1] where x is the pointer do AAPL.
I have to test functions - one based on memcpy and second based on for loop:
#include
#include
SEXP open(SEXP x) {
int nr=nrows(x);
SEXP r;
PROTECT(r=allocVector(REALSXP,nr));
memcpy(&REAL(r)[0],&REAL(x)[0],nr*sizeof(double));
UNPROTECT(1);
return(r);
}
SEXP open2(SEXP x) {
int P=0;
if (TYPEOF(x) != REALSXP) { PROTECT(x = coerceVector(x,REALSXP)); P++; }
double *d_x = REAL(x);
int nr = nrows(x);
SEXP s;
PROTECT(s = allocVector(REALSXP,nr));
P++;
double *d_s = REAL(s);
int i;
for (i=0;i # we have AAPL data in memory
>
> ls()
[1] "AAPL"
> tail(AAPL)
AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume AAPL.Adjusted
2010-09-02251.26252.17 248.57 252.1714811900252.17
2010-09-03255.09258.78 254.50 258.7718580100258.77
2010-09-07256.64259.53 256.25 257.8112234200257.81
2010-09-08259.78264.39 259.10 262.9218777000262.92
2010-09-09265.04266.52 262.92 263.0715642700263.07
>
> # now we call do open2 function
>
> .Call('open2',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
84.86 86.23 84.12
(...)
>
> # and now call to open based on memcpy
>
> .Call('open',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
84.86 86.23 84.12
(...)
AND HERE IS MY PROBLEM:
We download new data:
> getSymbols('IBM')
[1] "IBM"
>
> WE DOWNLOAD NEW DATA
>
> getSymbols('IBM')
[1] "IBM"
>
> # and try open2 function (based on for loop)
>
> .Call('open2',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14
(...)
>
> # now we try open function based on memcpy
> # ... and we will have a segfault
>
> .Call('open',AAPL)
*** caught segfault ***
address 0x2, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
I have this problem only if I download new data...
Do someone know how can I solve this memcpy problem? memcpy should be
much faster in this kind of area... and I want to write some C based
extensions for xts package.
Best regards,
daniel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [xts, quantmod] segfault probelm when I work with memcpy function
Daniel,
I haven't tried your example, but I wonder why you aren't using C
accessor methods defined by xts itself or at least derived from the
significant amounts of C code in xts.
For example, your test code seems to bear a close resemblance in
principle to coredata.c, but you don't appear to have used or derived
from that code.
I understand that your 'real' problem is likely different from your
contrived example, but it still seems that you should leverage the C
code already in xts where possible.
Regards,
- Brian
On 09/10/2010 12:27 PM, Daniel Cegiełka wrote:
Hi,
I work with SEXP C code and with xts and quantmod packages. I try to
touch how xts internal works.
So we have R session and:
ls()
character(0)
getSymbols('AAPL') # quantmod package
[1] "AAPL"
ls()
[1] "AAPL"
str(AAPL)
An ‘xts’ object from 2007-01-03 to 2010-09-09 containing:
Data: num [1:929, 1:6] 86.3 84 85.8 86 86.5 ...
- attr(*, "dimnames")=List of 2
..$ : NULL
..$ : chr [1:6] "AAPL.Open" "AAPL.High" "AAPL.Low" "AAPL.Close" ...
Indexed by objects of class: [Date] TZ:
xts Attributes:
List of 2
$ src: chr "yahoo"
$ updated: POSIXct[1:1], format: "2010-09-10 18:42:10"
tail(AAPL,5)
AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume AAPL.Adjusted
2010-09-02251.26252.17 248.57 252.1714811900252.17
2010-09-03255.09258.78 254.50 258.7718580100258.77
2010-09-07256.64259.53 256.25 257.8112234200257.81
2010-09-08259.78264.39 259.10 262.9218777000262.92
2010-09-09265.04266.52 262.92 263.0715642700263.07
q()
Save workspace image? [y/n/c]: y
[dan...@entropy ~]$
It's looks, that xts data in mamory looks like this (Open=o,High=h,Low=l etc):
o(...)oh(...)hl(...)lc(...)cv(...)va(...)a
So if I want to read Open price I need to read this array (from C
code) from x[0] to x[nrow(x)-1] where x is the pointer do AAPL.
I have to test functions - one based on memcpy and second based on for loop:
#include
#include
SEXP open(SEXP x) {
int nr=nrows(x);
SEXP r;
PROTECT(r=allocVector(REALSXP,nr));
memcpy(&REAL(r)[0],&REAL(x)[0],nr*sizeof(double));
UNPROTECT(1);
return(r);
}
SEXP open2(SEXP x) {
int P=0;
if (TYPEOF(x) != REALSXP) { PROTECT(x = coerceVector(x,REALSXP)); P++;
}
double *d_x = REAL(x);
int nr = nrows(x);
SEXP s;
PROTECT(s = allocVector(REALSXP,nr));
P++;
double *d_s = REAL(s);
int i;
for (i=0;i
# we have AAPL data in memory
ls()
[1] "AAPL"
tail(AAPL)
AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume AAPL.Adjusted
2010-09-02251.26252.17 248.57 252.1714811900252.17
2010-09-03255.09258.78 254.50 258.7718580100258.77
2010-09-07256.64259.53 256.25 257.8112234200257.81
2010-09-08259.78264.39 259.10 262.9218777000262.92
2010-09-09265.04266.52 262.92 263.0715642700263.07
# now we call do open2 function
.Call('open2',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
84.86 86.23 84.12
(...)
# and now call to open based on memcpy
.Call('open',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
84.86 86.23 84.12
(...)
AND HERE IS MY PROBLEM:
We download new data:
getSymbols('IBM')
[1] "IBM"
WE DOWNLOAD NEW DATA
getSymbols('IBM')
[1] "IBM"
# and try open2 function (based on for loop)
.Call('open2',AAPL)
[1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
97.56 92.10 88.63 89.14
(...)
# now we try open function based on memcpy
# ... and we will have a segfault
.Call('open',AAPL)
*** caught segfault ***
address 0x2, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
I have this problem only if I download new data...
Do someone know how can I solve this memcpy problem? memcpy should be
much faster in this kind of area... and I want to write some C based
extensions for xts package.
Best regards,
daniel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [xts, quantmod] segfault probelm when I work with memcpy function
W dniu 10 września 2010 20:32 użytkownik Brian G. Peterson
napisał:
> Daniel,
>
> I haven't tried your example, but I wonder why you aren't using C accessor
> methods defined by xts itself or at least derived from the significant
> amounts of C code in xts.
>
> For example, your test code seems to bear a close resemblance in principle
> to coredata.c, but you don't appear to have used or derived from that code.
I want to have a better expertise with SEXP and R and I hope in the
future I want to help to develop some R financial packages (xts, TTR
and blotter). So this is my main motivation.
>
> I understand that your 'real' problem is likely different from your
> contrived example, but it still seems that you should leverage the C code
> already in xts where possible.
I study xts code :) I could write some indicator in C and build xts
object directly from C, so you have only .Call('myind',IBM) and it's
return xts object. On large data and when you need to call this
function with high frequency it's much more faster then
.xts(.Call('myind',Cl(IBM)),getAttrib(IBM,'index')).
regards,
daniel
>
> Regards,
>
> - Brian
>
> On 09/10/2010 12:27 PM, Daniel Cegiełka wrote:
>>
>> Hi,
>>
>> I work with SEXP C code and with xts and quantmod packages. I try to
>> touch how xts internal works.
>>
>> So we have R session and:
>>
>>> ls()
>>
>> character(0)
>>>
>>> getSymbols('AAPL') # quantmod package
>>
>> [1] "AAPL"
>>>
>>> ls()
>>
>> [1] "AAPL"
>>>
>>> str(AAPL)
>>
>> An 'xts' object from 2007-01-03 to 2010-09-09 containing:
>> Data: num [1:929, 1:6] 86.3 84 85.8 86 86.5 ...
>> - attr(*, "dimnames")=List of 2
>> ..$ : NULL
>> ..$ : chr [1:6] "AAPL.Open" "AAPL.High" "AAPL.Low" "AAPL.Close" ...
>> Indexed by objects of class: [Date] TZ:
>> xts Attributes:
>> List of 2
>> $ src: chr "yahoo"
>> $ updated: POSIXct[1:1], format: "2010-09-10 18:42:10"
>>>
>>> tail(AAPL,5)
>>
>>AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume
>> AAPL.Adjusted
>> 2010-09-02251.26252.17 248.57 252.1714811900
>> 252.17
>> 2010-09-03255.09258.78 254.50 258.7718580100
>> 258.77
>> 2010-09-07256.64259.53 256.25 257.8112234200
>> 257.81
>> 2010-09-08259.78264.39 259.10 262.9218777000
>> 262.92
>> 2010-09-09265.04266.52 262.92 263.0715642700
>> 263.07
>>>
>>> q()
>>
>> Save workspace image? [y/n/c]: y
>> [dan...@entropy ~]$
>>
>>
>> It's looks, that xts data in mamory looks like this (Open=o,High=h,Low=l
>> etc):
>>
>> o(...)oh(...)hl(...)lc(...)cv(...)va(...)a
>>
>> So if I want to read Open price I need to read this array (from C
>> code) from x[0] to x[nrow(x)-1] where x is the pointer do AAPL.
>>
>>
>> I have to test functions - one based on memcpy and second based on for
>> loop:
>>
>>
>> #include
>> #include
>>
>> SEXP open(SEXP x) {
>> int nr=nrows(x);
>> SEXP r;
>> PROTECT(r=allocVector(REALSXP,nr));
>>
>> memcpy(&REAL(r)[0],&REAL(x)[0],nr*sizeof(double));
>>
>> UNPROTECT(1);
>> return(r);
>> }
>>
>>
>> SEXP open2(SEXP x) {
>> int P=0;
>> if (TYPEOF(x) != REALSXP) { PROTECT(x = coerceVector(x,REALSXP));
>> P++; }
>> double *d_x = REAL(x);
>> int nr = nrows(x);
>>
>> SEXP s;
>> PROTECT(s = allocVector(REALSXP,nr));
>> P++;
>> double *d_s = REAL(s);
>>
>> int i;
>> for (i=0;i>
>> UNPROTECT(P);
>> return(s);
>> }
>>
>> We starts R session again and:
>>
>>
>>> # we have AAPL data in memory
>>>
>>> ls()
>>
>> [1] "AAPL"
>>>
>>> tail(AAPL)
>>
>>AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume
>> AAPL.Adjusted
>> 2010-09-02251.26252.17 248.57 252.1714811900
>> 252.17
>> 2010-09-03255.09258.78 254.50 258.7718580100
>> 258.77
>> 2010-09-07256.64259.53 256.25 257.8112234200
>> 257.81
>> 2010-09-08259.78264.39 259.10 262.9218777000
>> 262.92
>> 2010-09-09265.04266.52 262.92 263.0715642700
>> 263.07
>>>
>>> # now we call do open2 function
>>>
>>> .Call('open2',AAPL)
>>
>> [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
>> 97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
>> 84.86 86.23 84.12
>>
>> (...)
>>
>>>
>>> # and now call to open based on memcpy
>>>
>>> .Call('open',AAPL)
>>
>> [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
>> 97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
>> 84.86 86.23 84.12
>>
>> (...)
>>
>>
>>
>> AND HERE IS MY PROBLEM:
>>
>> We download new data:
>>
>>> getSymbols('IBM')
>>
>> [1] "IBM"
>>>
>>> WE DOWNLOAD NEW DATA
>>>
>>> getSymbols('IBM')
>>
>> [1] "IBM"
>>>
>>> # and try open2 function (based on for loop)
>>>
>>> .Call('open2',AAPL)
>>
>> [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
>> 97.56 92.10
Re: [Rd] [xts, quantmod] segfault probelm when I work with memcpy function
You're right Simon. 'open' is so common name.. and it's probably used in
some other part of R. I reneme it's from "open" to "open1" and now it works
without segfaults.
Thanks,
daniel
W dniu 10 wrze¶nia 2010 20:52 u¿ytkownik Simon Urbanek <
simon.urba...@r-project.org> napisa³:
> Daniel,
>
> I doubt that your issue has anything to do with memcpy. Make sure you're
> really using the code that you think you're using (I suspect you are not)
> and run R -d gdb to find out more about your crash. As for the actual code -
> you should probably use the type check from open2() in open() as well.
>
> Cheers,
> Simon
>
>
> On Sep 10, 2010, at 1:27 PM, Daniel Cegie³ka wrote:
>
> > Hi,
> >
> > I work with SEXP C code and with xts and quantmod packages. I try to
> > touch how xts internal works.
> >
> > So we have R session and:
> >
> >> ls()
> > character(0)
> >> getSymbols('AAPL') # quantmod package
> > [1] "AAPL"
> >> ls()
> > [1] "AAPL"
> >> str(AAPL)
> > An 'xts' object from 2007-01-03 to 2010-09-09 containing:
> > Data: num [1:929, 1:6] 86.3 84 85.8 86 86.5 ...
> > - attr(*, "dimnames")=List of 2
> > ..$ : NULL
> > ..$ : chr [1:6] "AAPL.Open" "AAPL.High" "AAPL.Low" "AAPL.Close" ...
> > Indexed by objects of class: [Date] TZ:
> > xts Attributes:
> > List of 2
> > $ src: chr "yahoo"
> > $ updated: POSIXct[1:1], format: "2010-09-10 18:42:10"
> >> tail(AAPL,5)
> > AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume
> AAPL.Adjusted
> > 2010-09-02251.26252.17 248.57 252.1714811900
> 252.17
> > 2010-09-03255.09258.78 254.50 258.7718580100
> 258.77
> > 2010-09-07256.64259.53 256.25 257.8112234200
> 257.81
> > 2010-09-08259.78264.39 259.10 262.9218777000
> 262.92
> > 2010-09-09265.04266.52 262.92 263.0715642700
> 263.07
> >>
> >> q()
> > Save workspace image? [y/n/c]: y
> > [dan...@entropy ~]$
> >
> >
> > It's looks, that xts data in mamory looks like this (Open=o,High=h,Low=l
> etc):
> >
> > o(...)oh(...)hl(...)lc(...)cv(...)va(...)a
> >
> > So if I want to read Open price I need to read this array (from C
> > code) from x[0] to x[nrow(x)-1] where x is the pointer do AAPL.
> >
> >
> > I have to test functions - one based on memcpy and second based on for
> loop:
> >
> >
> > #include
> > #include
> >
> > SEXP open(SEXP x) {
> >int nr=nrows(x);
> >SEXP r;
> >PROTECT(r=allocVector(REALSXP,nr));
> >
> >memcpy(&REAL(r)[0],&REAL(x)[0],nr*sizeof(double));
> >
> >UNPROTECT(1);
> >return(r);
> > }
> >
> >
> > SEXP open2(SEXP x) {
> >int P=0;
> >if (TYPEOF(x) != REALSXP) { PROTECT(x = coerceVector(x,REALSXP));
> P++; }
> >double *d_x = REAL(x);
> >int nr = nrows(x);
> >
> >SEXP s;
> >PROTECT(s = allocVector(REALSXP,nr));
> >P++;
> >double *d_s = REAL(s);
> >
> >int i;
> >for (i=0;i >
> >UNPROTECT(P);
> >return(s);
> > }
> >
> > We starts R session again and:
> >
> >
> >> # we have AAPL data in memory
> >>
> >> ls()
> > [1] "AAPL"
> >> tail(AAPL)
> > AAPL.Open AAPL.High AAPL.Low AAPL.Close AAPL.Volume
> AAPL.Adjusted
> > 2010-09-02251.26252.17 248.57 252.1714811900
> 252.17
> > 2010-09-03255.09258.78 254.50 258.7718580100
> 258.77
> > 2010-09-07256.64259.53 256.25 257.8112234200
> 257.81
> > 2010-09-08259.78264.39 259.10 262.9218777000
> 262.92
> > 2010-09-09265.04266.52 262.92 263.0715642700
> 263.07
> >>
> >> # now we call do open2 function
> >>
> >> .Call('open2',AAPL)
> > [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
> > 97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
> > 84.86 86.23 84.12
> >
> > (...)
> >
> >>
> >> # and now call to open based on memcpy
> >>
> >> .Call('open',AAPL)
> > [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
> > 97.56 92.10 88.63 89.14 85.73 86.68 87.11 87.11 86.30 86.43
> > 84.86 86.23 84.12
> >
> > (...)
> >
> >
> >
> > AND HERE IS MY PROBLEM:
> >
> > We download new data:
> >
> >> getSymbols('IBM')
> > [1] "IBM"
> >>
> >> WE DOWNLOAD NEW DATA
> >>
> >> getSymbols('IBM')
> > [1] "IBM"
> >>
> >> # and try open2 function (based on for loop)
> >>
> >> .Call('open2',AAPL)
> > [1] 86.29 84.05 85.77 85.96 86.45 94.75 95.94 94.59 95.68
> > 97.56 92.10 88.63 89.14
> >
> > (...)
> >
> >>
> >> # now we try open function based on memcpy
> >> # ... and we will have a segfault
> >>
> >> .Call('open',AAPL)
> >
> > *** caught segfault ***
> > address 0x2, cause 'memory not mapped'
> >
> > Possible actions:
> > 1: abort (with core dump, if enabled)
> > 2: normal R exit
> > 3: exit R without saving workspace
> > 4: exit R saving workspace
> > Selection: 3
> >
> >
> > I have this problem only if I download new data...
> >
> > Do someon
[Rd] Windows build
Hi Folks, I am trying to build R-2.11.1 from source code on Windows 2003. I am able to build it, but when i run 'make check', it fails as follows: Does the tests produce a log somewhere that i can use for troubleshooting the problem ? - C:\R\R-2.11.1\src\gnuwin32>make check Collecting examples for package 'base' Extracting from parsed Rd's Running examples in package 'base' Collecting examples for package 'tools' Extracting from parsed Rd's Running examples in package 'tools' Collecting examples for package 'utils' Extracting from parsed Rd's . Running examples in package 'utils' Error: testing 'utils' failed Execution halted make[3]: *** [test-Examples-Base] Error 1 make[2]: *** [test-Examples] Error 2 make[1]: *** [test-all-basics] Error 1 make: *** [check] Error 2 Thanks, Pooja __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows build
On 10/09/2010 5:05 PM, pooja varshneya wrote: Hi Folks, I am trying to build R-2.11.1 from source code on Windows 2003. I am able to build it, but when i run 'make check', it fails as follows: Does the tests produce a log somewhere that i can use for troubleshooting the problem ? - C:\R\R-2.11.1\src\gnuwin32>make check Collecting examples for package 'base' Extracting from parsed Rd's Running examples in package 'base' Collecting examples for package 'tools' Extracting from parsed Rd's Running examples in package 'tools' Collecting examples for package 'utils' Extracting from parsed Rd's . Running examples in package 'utils' Error: testing 'utils' failed Execution halted make[3]: *** [test-Examples-Base] Error 1 make[2]: *** [test-Examples] Error 2 make[1]: *** [test-all-basics] Error 1 make: *** [check] Error 2 Yes, if you look in the R_HOME/tests directory, you'll see a subdirectory named Examples; that's where the logs of all the tests of examples are saved. But I can guess at the problem: you don't have the recommended packages installed. They're needed to run the tests. In Windows you get them by make rsync-recommended make recommended Getting them in other OS's is slightly different, but I forget the details. See the R Installation and Administration manual. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Hi,
I found the following problem with recent R-devel
(2010-08-26 r52817) on Windows (32-bit and 64-bit):
'R CMD build ' gets stalled during vignette
creation for packages that have a Makefile in /inst/doc.
It seems that the problem is that the commands used in the
Makefile for converting .tex to .pdf are not able to locate
the Sweave.sty file anymore (if I drop this file to
/inst/doc, then the problem goes away).
I noticed that the location of Sweave.sty shipped with
R has changed recently (moved from ${R_HOME}/share/texmf
to ${R_HOME}/share/texmf/tex/latex/). Could that be related
to the problem?
I don't see that problem on platforms other than Windows or
with R < 2.12
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
