[Rd] Speed of for loops
Hi Everyone,
I have a question about for loops. If you have something like:
f <- function(x) {
y <- rep(NA,10);
for( i in 1:10 ) {
if ( i > 3 ) {
if ( is.na(y[i-3]) == FALSE ) {
# some calculation F which depends on one or
more of the previously
generated values in the series
y[i] = y[i-1]+x[i];
} else {
y[i] <- x[i];
}
}
}
y
}
e.g.
> f(c(1,2,3,4,5,6,7,8,9,10,11,12));
[1] NA NA NA 4 5 6 13 21 30 40
is there a faster way to process this than with a 'for' loop? I have
looked at lapply as well but I have read that lapply is no faster than a
for loop and for my particular application it is easier to use a for loop.
Also I have seen 'rle' which I think may help me but am not sure as I have
only just come across it, any ideas?
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of for loops
Thank you all for your advice and tips. In the end, I think the for loop
is the easiest way forward due to other requirements but its good to know
that I haven't missed anything too obvious.
Tom
On Tue, 30 Jan 2007 23:42:27 -, Oleg Sklyar <[EMAIL PROTECTED]> wrote:
> It is surely an elegant way of doing things (although far from being
> easy to parse visually) but is it really faster than a loop?
>
> After all, the indexing problem is the same and sapply simply does the
> same job as for in this case, plus "<<-" will _search_ through the
> environment on every single step. Where is the gain?
>
> Oleg
>
> --
> Dr Oleg Sklyar | EBI-EMBL, Cambridge CB10 1SD, UK | +44-1223-494466
>
>
> Byron Ellis wrote:
>> Actually, why not use a closure to store previous value(s)?
>>
>> In the simple case, which depends on x_i and y_{i-1}
>>
>> gen.iter = function(x) {
>> y = NA
>> function(i) {
>>y <<- if(is.na(y)) x[i] else y+x[i]
>> }
>> }
>>
>> y = sapply(1:10,gen.iter(x))
>>
>> Obviously you can modify the function for the bookkeeping required to
>> manage whatever lag you need. I use this sometimes when I'm
>> implementing MCMC samplers of various kinds.
>>
>>
>> On 1/30/07, Herve Pages <[EMAIL PROTECTED]> wrote:
>>> Tom McCallum wrote:
>>>> Hi Everyone,
>>>>
>>>> I have a question about for loops. If you have something like:
>>>>
>>>> f <- function(x) {
>>>> y <- rep(NA,10);
>>>> for( i in 1:10 ) {
>>>> if ( i > 3 ) {
>>>> if ( is.na(y[i-3]) == FALSE ) {
>>>> # some calculation F which depends on
>>>> one or more of the previously
>>>> generated values in the series
>>>> y[i] = y[i-1]+x[i];
>>>> } else {
>>>> y[i] <- x[i];
>>>> }
>>>> }
>>>> }
>>>> y
>>>> }
>>>>
>>>> e.g.
>>>>
>>>>> f(c(1,2,3,4,5,6,7,8,9,10,11,12));
>>>> [1] NA NA NA 4 5 6 13 21 30 40
>>>>
>>>> is there a faster way to process this than with a 'for' loop? I have
>>>> looked at lapply as well but I have read that lapply is no faster
>>>> than a
>>>> for loop and for my particular application it is easier to use a for
>>>> loop.
>>>> Also I have seen 'rle' which I think may help me but am not sure as I
>>>> have
>>>> only just come across it, any ideas?
>>> Hi Tom,
>>>
>>> In the general case, you need a loop in order to propagate calculations
>>> and their results across a vector.
>>>
>>> In _your_ particular case however, it seems that all you are doing is a
>>> cumulative sum on x (at least this is what's happening for i >= 6).
>>> So you could do:
>>>
>>> f2 <- function(x)
>>> {
>>> offset <- 3
>>> start_propagate_at <- 6
>>> y_length <- 10
>>> init_range <- (offset+1):start_propagate_at
>>> y <- rep(NA, offset)
>>> y[init_range] <- x[init_range]
>>> y[start_propagate_at:y_length] <-
>>> cumsum(x[start_propagate_at:y_length])
>>> y
>>> }
>>>
>>> and it will return the same thing as your function 'f' (at least when
>>> 'x' doesn't
>>> contain NAs) but it's not faster :-/
>>>
>>> IMO, using sapply for propagating calculations across a vector is not
>>> appropriate
>>> because:
>>>
>>> (1) It requires special care. For example, this:
>>>
>>> > x <- 1:10
>>> > sapply(2:length(x), function(i) {x[i] <- x[i-1]+x[i]})
>>>
>>> doesn't work because the 'x' symbol on the left side of the <-
>>> in the
>>> anonymous function doesn't refer to the 'x' symbol defined in
>>> the global
>>> environment. So you need to use tricks like this:
>>>
>>> > sapply(2:length(x),
>>> function(i) {x[i] <- x[i-1]+x[i]; assign("x", x,
>>> envir=.GlobalEnv); x[i]})
>>>
>>> (2) Because of this kind of tricks, then it is _very_ slow (about 10
>>> times
>>> slower or more than a 'for' loop).
>>>
>>> Cheers,
>>> H.
>>>
>>>
>>>> Many thanks
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Best Practise
Hello,
Just a quick question on best practise. I am converting quite a bit of
legacy C code into R packages and have the following situation:
(1) Legacy object with a double* array in, all over code so don't want to
change any more than I have to.
(2) Do something like:
SEXP arrayToPassToR;
PROTECT( arrayToPassToR = allocVector( REALSXP, n ) );
for(i=0; i < n; i++) {
REAL(arrayToPassToR)[i] = oldCarray[i]; < very slow way
to copy
data, can I use memcpy/pointer assignment here to remove the loop without
running into garbage collector?
}
UNPROTECT( arrayToPassToR );
SEXP returnValueFromR;
(3) Have made it to call back to an R function which returns a new /
different SEXP double array.
returnValueFromR = Test_tryEval(...);
(4) Copy back to oldCArray
for(i=0; i < n; i++) {
oldCarray[i] = REAL(returnValueFromR)[i]; <--- can I use
memcpy/pointer
assignment here to remove loop?
}
UNPROTECT(1);
I have done the long winded copy as I am a bit paranoid about the garbage
collection. My question is is it legitimate to do the following
double* oldCArray = REAL(arrayToPassToR);
UNPROTECT(1); // where the 1 would remove protection from
arrayToPassToR
and potential garbage collection
-- assume arrayToPassToR was garbage collected by R --
Rprintf("%f", oldCArray[0]);
because if arrayToPassToR is garbage collected then oldCArray will cause a
SEGFAULT when it is accessed afterwards, won't it?
Many thanks
Tom
--
PS Note this is the new email address - delete [EMAIL PROTECTED] as it
won't work soon!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DataTime field when converting between database formats
I was recently converting a MS-Access database to MySQL when I came across this error: Error in fromchar(unclass(x)) : character string is not in a standard unambiguous format The error occurs because the NULL value of a DateTime field, if not properly setup or on export to a CSV, can be set to '-00-00 00:00:00' which fails the NA test in R-2.6.2/src/library/base/R/datetime.R on line 32. Can I recommend that this either raises a more specific error, or that it automatically converts this value to NA and perhaps outputs a warning. For now I have fixed the incoming data, but thought I would register this behaviour in case anyone else came across it. Best, Tom __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RODBC Close Memory Leak Question
Hi everyone,
In relation to the RODBC odbcClose bug which was fixed back in the
changelog below:
Version: 1.2-3 (2008-01-24, released)
* Plug a memory leak in inRODBCClose (closing a connection),
reported by Stephan Henne.
* Use translateChar() on character data sent in.
Background:
I am running some data from a SQL Server database, through unixODBC
(freetds) into R via the RODBC package. If I make many calls to
odbcConnect, perform a query and then close the connection over a period
of time the memory attached appears never to be freed and the process
eventually - say 4 hours into the run - dies due to lack of memory.
Research:
I have created a dummy piece of code which shows the growing memory
allocation shown below. Each call brings back between 20-100 pieces of
data which fits into a one column vector - so not a lot of data. The
varible x is normally returns from a function and used subsequently but
for the purposes of this test I have kept it simple.
library("RODBC")
for( i in 1:100 ) {
conn <- odbcConnect()
<-- anonymised
x <- sqlQuery(conn, "SELECT * FROM table_name"); <--
anonymised
odbcClose(conn);
}
quit()
I am not sure whether the leak is related to this previous bug or if it is
related to the way the garbage collection works, but either way if I run
this piece of code the memory attached to the database handle is never
freed so as I bring back more and more data over a large number of runs my
memory slowly fills up and the application crashes, unable to allocate any
more memory.
Just to make sure I was running the latest and greatest RODBC I installed
it again from source, but the initial installation was only done last
month so I presume .install.packages would have got this latest version
anyway.
Any advice on where to start searching to patch this as it is a real
pain. I have included below version information and the valgrind
output. If this is a new bug I will add it the bug tracker but I wanted
to make sure I was not missing anything blindingly obvious to someone in
the know.
Thanks for your help,
Tom
version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 7.0
year 2008
month 04
day22
svn rev45424
language R
version.string R version 2.7.0 (2008-04-22)
==8682== Memcheck, a memory error detector.
==8682== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==8682== Using LibVEX rev 1471, a library for dynamic binary translation.
==8682== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==8682== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==8682== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==8682== For more details, rerun with: -v
==8682==
R version 2.7.0 (2008-04-22)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
library("RODBC")
--8682-- WARNING: unhandled syscall: 311
--8682-- You may be able to write your own handler.
--8682-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
for( i in 1:100 ) {
+ conn <- odbcConnect() <--
anonymised
+ x <- sqlQuery(conn, "SELECT * FROM table_name"); <--
anonymised
+ odbcClose(conn);
+ }
quit()
==8682==
==8682== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 255 from 1)
==8682== malloc/free: in use at exit: 13,470,816 bytes in 6,739 blocks.
==8682== malloc/free: 121,121 allocs, 114,382 frees, 134,084,145 bytes
allocated.
==8682== For counts of detected errors, rerun with: -v
==8682== searching for pointers to 6,739 not-freed blocks.
==8682== checked 13,332,140 bytes.
==8682==
==8682== 56 bytes in 1 blocks are possibly lost in loss record 15 of 55
==8682==at 0x40045EB: calloc (vg_replace_malloc.c:279)
==8682==by 0x805AA60: R_chk_calloc (memory.c:2368)
==8682==by 0x57C89D6: RODBCDriverConnect (RODBC.c:244)
==8682==by 0x8160A68: do_dotcall (dotcode.c:863)
==8682==by 0x81857CE: Rf_eval (eval.c:489)
==8682==by 0x81895B7: do_set (eval.c:1420)
==8682==by 0x81855B0: Rf_eval (eval.c:463)
==8682==by 0x818631E: do_begin (eval.c:1172)
==8682==by 0x81855B0: Rf_eval (eval.c:463)
==8682==
[Rd] RODBC Seg Fault
Hi Everyone,
At the end of this email is a transcript of a problem I have found in
RODBC version 2.3-1. It appears that the bug fix in odbcClose for the
memory leak has meant that the garbage collector is falling over when it
tries to free up the extPtr attribute of the RODBC connection pointer.
Any advice on how to fix this?
Thanks for your help,
Tom
##---
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 7.1
year 2008
month 06
day23
svn rev45970
language R
version.string R version 2.7.1 (2008-06-23)
##---
Run using the command
$ R -d gdb
##---
Starting program: /usr/local/lib/R/bin/exec/R
R version 2.7.1 (2008-06-23)
Copyright (C) 2008 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
[Previously saved workspace restored]
library("RODBC")
[Thread debugging using libthread_db enabled]
[New Thread -1208248640 (LWP 14060)]
Error while reading shared library symbols:
Cannot find new threads: generic error
gctorture(TRUE)
for(i in 1:10) { print(i); conn <- odbcConnect("***", "***", "***");
print(conn); odbcClose(conn) }
[1] 1
RODB Connection 2
Details:
case=nochange
DSN=***
UID=***
PWD=***
[1] 2
RODB Connection 3
Details:
case=nochange
DSN=***
UID=***
PWD=***
[1] 3
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208248640 (LWP 14060)]
0x08059036 in R_ClearExternalPtr (s=0x0) at memory.c:2445
2445memory.c: No such file or directory.
in memory.c
(gdb) bt
#0 0x08059036 in R_ClearExternalPtr (s=0x0) at memory.c:2445
#1 0x006b17cb in inRODBCClose (thisHandle=0x8c1f358) at RODBC.c:1250
#2 0x006b190d in chanFinalizer (ptr=0x9100380) at RODBC.c:1271
#3 0x0805b6eb in R_RunWeakRefFinalizer (w=0x90da4f8) at memory.c:1062
#4 0x0805b810 in RunFinalizers () at memory.c:1107
#5 0x0805cf17 in R_gc_internal (size_needed=1) at memory.c:2205
#6 0x0805da69 in Rf_allocVector (type=16, length=1) at memory.c:1968
#7 0x006b3955 in RODBCDriverConnect (connection=0x90b0208, id=0x90b0288,
useNRows=0x90b02c8) at RODBC.c:277
#8 0x08161a19 in do_dotcall (call=0x89b9ba8, op=0x85518dc, args=optimized out>, env=0x9100e44) at dotcode.c:863
#9 0x0818683f in Rf_eval (e=0x89b9ba8, rho=0x9100e44) at eval.c:489
#10 0x0818a628 in do_set (call=0x89b9b1c, op=0x8546120, args=optimized out>, rho=0x9100e44) at eval.c:1424
#11 0x08186621 in Rf_eval (e=0x89b9b1c, rho=0x9100e44) at eval.c:463
#12 0x0818737f in do_begin (call=0x89ba260, op=0x8547788, args=0x89b9b00,
rho=0x9100e44) at eval.c:1176
#13 0x08186621 in Rf_eval (e=0x89ba260, rho=0x9100e44) at eval.c:463
#14 0x08188a15 in Rf_applyClosure (call=0x89bbda4, op=0x89bac60,
arglist=0x9100bf8, rho=0x9100a38, suppliedenv=0x855a084) at eval.c:669
#15 0x081864da in Rf_eval (e=0x89bbda4, rho=0x9100a38) at eval.c:507
#16 0x0818737f in do_begin (call=0x89bb90c, op=0x8547788, args=0x89bbd88,
rho=0x9100a38) at eval.c:1176
#17 0x08186621 in Rf_eval (e=0x89bb90c, rho=0x9100a38) at eval.c:463
#18 0x08188a15 in Rf_applyClosure (call=0x8e5bcd0, op=0x89bcc80,
arglist=0x9100894, rho=0x855a068, suppliedenv=0x855a084) at eval.c:669
#19 0x081864da in Rf_eval (e=0x8e5bcd0, rho=0x855a068) at eval.c:507
#20 0x0818a628 in do_set (call=0x8e5ba30, op=0x8546120, args=optimized out>, rho=0x855a068) at eval.c:1424
#21 0x08186621 in Rf_eval (e=0x8e5ba30, rho=0x855a068) at eval.c:463
#22 0x0818737f in do_begin (call=0x8e5991c, op=0x8547788, args=0x8e597e8,
rho=0x855a068) at eval.c:1176
#23 0x08186621 in Rf_eval (e=0x8e5991c, rho=0x855a068) at eval.c:463
#24 0x08189fb3 in do_for (call=0x8e59820, op=0x8536d78, args=0x8e59938,
rho=0x855a068) at eval.c:1075
#25 0x08186621 in Rf_eval (e=0x8e59820, rho=0x855a068) at eval.c:463
#26 0x080587e0 in Rf_ReplIteration (rho=0x855a068, savestack=0,
browselevel=0, state=0xbf833d28) at main.c:257
#27 0x08058b4a in R_ReplConsole (rho=0x855a068, savestack=0,
browselevel=0) at main.c:306
#28 0x08058e28 in run_Rmainloop () at main.c:967
#29 0x08056731 in main (ac=Cannot access memory at address 0x0
) at Rmain.c:35
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/lis
[Rd] Memory problems with a custom R package
Hi everyone,
I have been attempting to build a very simple R package interfacing with
some very simple C++ code. Everything I try though results in the
function working but on return it produces a memory error. Here is the
output:
***OUTPUT***
> library(MyPackage)
> hello();
*** caught segfault ***
address 0x3, cause 'memory not mapped'
**END OUTPUT*
I have read that some time this occurs because it cannot find the function
in the shared library but I have tested this theory with a simple text
message and this is displayed but again the memory error occurs.
The C++ code has been reduced to the simplest possible:
*** helloworld.h
extern "C" void helloworld(void);
*** helloworld.cpp
#include
#include "helloworld.h"
void helloworld(void) {
// This was my test line that was displayed as described above.
// std::cout << "My first R Package Test." << std::endl;
}
I also wrote an R wrapper called hello as follows:
*** helloworld.R
hello <- function()
{
.Call("helloworld", PACKAGE="MyPackage");
}
The namespaces file (NAMESPACE) is as follows:
useDynLib(MyPackage)
export(hello)
I have compared mine against other package sources available that do the
same thing and cannot find the key difference.
Thank you for your help in advance,
Tom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] time_t handling in R
Hello all, I am converting some C code into a package for R and wondered what the proper way of handling time_t types from C in R was. time_t is a typedef for long, but R seems to only deal in Integers or Reals, so what is the proper way of handling time in an R to C conversion ( or visa versa )? Many thanks Tom -- Thomas McCallum Systems Architect LevelE Limited Phone: 0131 - 4724813 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cross-compilation
Hi everyone, I am trying to cross-compile a package I wrote using the Yan and Rossini tutorial "Building Microsoft Windows versions of R and R packages using Intel Linux". I have got reasonably far with this but when doing the linking using the line: i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR I get lots of these type of messages: /my/path/to/mylibrary.cpp:43: undefined reference to `_GLOBAL_OFFSET_TABLE_' and other similar linker errors for virtually every object and command in the program. After some googling I have found that there may be problems with the libgcc.a library and its default -fPIC argument during compilation. Has anyone got this tutorial to work and if so how did they overcome this? I am attempting to do this on Fedora Core 4 on a 32-bit machine, having completed all the previous sections of the tutorial for building a cross-platform version of R. Many thanks Tom -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cross-compilation
Thanks for your reply, as an example it appears to have difficulty linking to even ostream library of the standard C++, as shown below: /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' Classifier.o: In function `operator<<': /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: undefined reference to `_ZNSolsEd' /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: undefined reference to `_ZNSolsEl' I am currently working R-2.4.0 as downloaded today. I know the g++ has gone through some alterations and wondered if you knew the version of g++ you cross-compiled your package with for comparison - mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). Many thanks Tom On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> wrote: > Dear Tom, > > It has worked for me out-of-the box in at least two times, one a while > ago > with R-2.2-something and recently with R-2.4.0. In both cases, I was > running > Debian (with a mix of testing and unstable) on x86. I never had to do > anything, just run the script and at least in one case I did > crosscompile a > package with C++. > > > R. > > On Wednesday 25 October 2006 18:03, Tom McCallum wrote: >> Hi everyone, >> >> I am trying to cross-compile a package I wrote using the Yan and Rossini >> tutorial "Building Microsoft Windows versions of R and R packages using >> Intel Linux". I have got reasonably far with this but when doing the >> linking using the line: >> >> i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o >> mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR >> >> I get lots of these type of messages: >> /my/path/to/mylibrary.cpp:43: undefined reference to >> `_GLOBAL_OFFSET_TABLE_' >> >> and other similar linker errors for virtually every object and command >> in >> the program. After some googling I have found that there may be >> problems >> with the libgcc.a library and its default -fPIC argument during >> compilation. >> >> Has anyone got this tutorial to work and if so how did they overcome >> this? >> >> I am attempting to do this on Fedora Core 4 on a 32-bit machine, having >> completed all the previous sections of the tutorial for building a >> cross-platform version of R. >> >> Many thanks >> >> Tom > -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Overloading functions
Hi Everyone
I have a function f which does something using a function g. Function f
is in a library and g has a default stub in the library but will be mainly
overloaded in a later R script. For example:
## In a compiled package 'P' #
g <- function() {
cat("Original function g");
}
f <- function( newGsource=NULL ) {
if( is.null(newGsource) == FALSE ) {
source( newGsource ); # load new function g
}
g();
return(1);
}
#
If I call f() then I get "Original function g".
But I want to overload g so I do the following in the file newg.R:
### CONTENTS of newg.R ##
g <- function() {
cat("New function g in newg.R");
}
END CONTENTS ###
and call f( newGsource="newg.R" ) but I still get "Original function g".
Any suggestions?
Tom
--
---
Tom McCallum
WWW: http://www.tom-mccallum.com
Tel: 0131-4783393
Mobile: 07866-470257
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading functions
On Fri, 27 Oct 2006 14:49:15 +0100, Paul Roebuck <[EMAIL PROTECTED]>
wrote:
> On Fri, 27 Oct 2006, Tom McCallum wrote:
>
>> I have a function f which does something using a function g. Function f
>> is in a library and g has a default stub in the library but will be
>> mainly
>> overloaded in a later R script. For example:
>>
>> ## In a compiled package 'P' #
>> g <- function() {
>> cat("Original function g");
>> }
>>
>> f <- function( newGsource=NULL ) {
>> if( is.null(newGsource) == FALSE ) {
>> source( newGsource ); # load new function g
>> }
>> g();
>> return(1);
>> }
>> #
>>
>> If I call f() then I get "Original function g".
>>
>> But I want to overload g so I do the following in the file newg.R:
>>
>> ### CONTENTS of newg.R ##
>> g <- function() {
>> cat("New function g in newg.R");
>> }
>> END CONTENTS ###
>>
>> and call f( newGsource="newg.R" ) but I still get "Original function g".
>>
>> Any suggestions?
>
> ?environment
>
> --
> SIGSIG -- signature too long (core dumped)
>
>
Thanks for that, have almost figured out how to do it, have got my
namespace but when I "assign" the new value
I get "cannot change value of a locked binding". Is there any way to say
that a particular item in a package
is able to be overridden using assign?
I assume when I export a function in the NAMESPACE file it is locking the
value to the name. So I assume it is here I need
to change something - if this is even possible to do.
Cheers
Tom
--
---
Tom McCallum
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overloading functions
On Fri, 27 Oct 2006 15:54:40 +0100, Tom McCallum <[EMAIL PROTECTED]>
wrote:
> On Fri, 27 Oct 2006 14:49:15 +0100, Paul Roebuck <[EMAIL PROTECTED]>
> wrote:
>
>> On Fri, 27 Oct 2006, Tom McCallum wrote:
>>
>>> I have a function f which does something using a function g. Function
>>> f
>>> is in a library and g has a default stub in the library but will be
>>> mainly
>>> overloaded in a later R script. For example:
>>>
>>> ## In a compiled package 'P' #
>>> g <- function() {
>>> cat("Original function g");
>>> }
>>>
>>> f <- function( newGsource=NULL ) {
>>> if( is.null(newGsource) == FALSE ) {
>>> source( newGsource ); # load new function g
>>> }
>>> g();
>>> return(1);
>>> }
>>> #
>>>
>>> If I call f() then I get "Original function g".
>>>
>>> But I want to overload g so I do the following in the file newg.R:
>>>
>>> ### CONTENTS of newg.R ##
>>> g <- function() {
>>> cat("New function g in newg.R");
>>> }
>>> END CONTENTS ###
>>>
>>> and call f( newGsource="newg.R" ) but I still get "Original function
>>> g".
>>>
>>> Any suggestions?
>>
>> ?environment
>>
>> --
>> SIGSIG -- signature too long (core dumped)
>>
>>
>
> Thanks for that, have almost figured out how to do it, have got my
> namespace but when I "assign" the new value
> I get "cannot change value of a locked binding". Is there any way to say
> that a particular item in a package
> is able to be overridden using assign?
>
> I assume when I export a function in the NAMESPACE file it is locking the
> value to the name. So I assume it is here I need
> to change something - if this is even possible to do.
>
> Cheers
>
> Tom
>
found the use of assignInNamespace - done!
Thanks for your help.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] variable problem
Hi everyone,
I am not sure this is possible so I would be interested in your
responses. Say I have a variable 'v' with the string "myargument" in and
I have a function 'f' that takes this argument as follows;
f <- function( myargument=5 ) {
... does something...
}
Is there anyway I can say something like;
f( v=10 ) such that it will be evaluated as f( myargument=10 ).
I presume there may be some use eval and substitute but if someone could
point me in the right direction then that would be great.
The end idea is to have a list of m items, declared somewhere else, which
can be evaluated as particular arguments named after their list names
e.g
mylist <- list( "a"=1, "b"=2, "c"=3 )
which can be passed to a function taking arguments a,b, or c and it will
be able to evaluate them accordingly :
long hand this would evaluate to something like
f( a=mylist[["a"]] );
f( b=mylist[["b"]] );
f( c=mylist[["c"]] );
but I would have actually rewritten something like
for ( myvar in names( mylist ) ) {
f( some_clever_substitution_to_act_as_argument(myvar) =
mylist[[ myvar
]] );
}
I hope I have explained myself clearly enough, if not please say so and I
will try and give a better example.
Many thanks for your help
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable problem
Works like a charm - thank you very much.
Tom
On Tue, 07 Nov 2006 20:45:04 -, Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> On Tuesday 07 November 2006 3:28 pm, Tom McCallum wrote:
>> Hi everyone,
>
> Hi Tom,
>
> Would this snippet work:
>
> for(i in 1:length(mylist))do.call(f, mylist[i])
>
> On the other hand it is not easy to see why you would want to call
> the
> same function with differently named arguments - perhaps what you are
> really
> trying to do has a different (and better) solution ?
>
>best
>
> Vladimir Dergachev
>
>>
>> I am not sure this is possible so I would be interested in your
>> responses. Say I have a variable 'v' with the string "myargument" in
>> and
>> I have a function 'f' that takes this argument as follows;
>>
>> f <- function( myargument=5 ) {
>>... does something...
>> }
>>
>> Is there anyway I can say something like;
>>
>> f( v=10 ) such that it will be evaluated as f( myargument=10 ).
>>
>> I presume there may be some use eval and substitute but if someone could
>> point me in the right direction then that would be great.
>>
>> The end idea is to have a list of m items, declared somewhere else,
>> which
>> can be evaluated as particular arguments named after their list names
>>
>> e.g
>>
>> mylist <- list( "a"=1, "b"=2, "c"=3 )
>>
>> which can be passed to a function taking arguments a,b, or c and it will
>> be able to evaluate them accordingly :
>>
>> long hand this would evaluate to something like
>> f( a=mylist[["a"]] );
>> f( b=mylist[["b"]] );
>> f( c=mylist[["c"]] );
>>
>> but I would have actually rewritten something like
>> for ( myvar in names( mylist ) ) {
>> f( some_clever_substitution_to_act_as_argument(myvar) =
>> mylist[[ myvar
>> ]] );
>> }
>>
>> I hope I have explained myself clearly enough, if not please say so and
>> I
>> will try and give a better example.
>>
>> Many thanks for your help
>>
>> Tom
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Retrieving function name
Hi,
Does anyone know how I can retrieve a function name, for example
If I have a function f as follows:
f <- function( myfunc ) {
print( name_of(myfunc) );
}
I want to know what I should have as "name_of" such that I could call this
with :
f( median )
and it would print "median"
or f( my_function_name ) and it would print "m_function_name".
So far all I can get is the function definition that myfunc points to.
I thought the structure command might do it but this also just gives back
the function definition and not the original name.
Any suggestions?
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] String to list and visa versa
Hi, I need to collapse a list into a string and then reparse it back into the list. Normally when I need to do this I simply use write.csv and read.csv, but I need to do this in memory within R rather than writing out to file. Are there any bespoke commands that any knows of that does something like this or any tips for doing this that anyone can suggest? I basically don't care upon the string representation, only that I can manipulate the list as a string and then reparse it back to a valid list object. Many thanks for your help, Tom -- Dr. Thomas McCallum Systems Architect, Level E Limited ETTC, The King's Buildings Mayfield Road, Edinburgh EH9 3JL, UK Work +44 (0) 131 472 4813 Fax: +44 (0) 131 472 4719 http://www.levelelimited.com Email: [EMAIL PROTECTED] Level E is a limited company incorporated in Scotland. The contents of this e-mail are privileged and/or confidential. If you are not the intended recipient, please notify the sender and ensure this e-mail is deleted and not read, copied or disclosed. It is your responsibility to scan this e-mail and any attachments for computer viruses or other defects. Level E does not accept liability for any loss or damage which may result from this e-mail or any attachment. E-mail is not secure and can be intercepted, corrupted or amended. Level E does not accept liability for errors or omissions arising as a result of interrupted or defective transmission. Any views, opinions, conclusions or other information in this e-mail which do not relate to the business of Level E Limited are not authorised by Level E. Unless specifically stated and authorised by Level E, nothing in this e-mail shall be taken to be an offer or acceptance of any contract of any nature. E-mail entering or leaving Level E's system is subject to random monitoring and recording. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] String to list and visa versa
On Wed, 15 Nov 2006 05:00:28 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Tue, 14 Nov 2006, Vladimir Dergachev wrote:
>
>> On Tuesday 14 November 2006 12:28 pm, Prof Brian Ripley wrote:
>>> This approach won't work in very many cases (but then nor will
>>> write.csv).
>>>
>>> The safest way I know is to use serialize() and unserialize(). Next to
>>> that, deparse(control="all") and parse(text=) are quite good and give a
>>> human-readable character representation.
>>>
>>> If fidelity is not the main issue, as.character and toString spring to
>>> mind. unlist is recursive, and is not going to come close to being
>>> faithful for other than very simple lists. And what if ',' is a
>>> character
>>> in one of the list elements?
>>
>> Yes, but then one can replace ',' with something rarely used like \007.
>> I picked ',' because write.csv/read.csv worked before.
>
> But it quotes strings
>
>> You are right, for storage serialize/unserialize seem best, however for
>> manipulation one would usually prefer a well-defined format.
>
>
Thanks for the information, I think I am going to use the
serialize/unserialize methods, which will mean I can't manipulate them
outside R, but I can alter other parts of the project to accomodate this.
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Manipulating R lists in C
Hi,
I have been studying the R manual on lists but cannot seem to create a
simple R list in C - I keep on getting "'dimnames' applied to non-array"
whenever I attempt to assign names to the list elements:
Wanted output a list structure something like
[ type="Bid", price=2.0, volume=1000 ]
I can get up to a list of
[ "Bid2, 2.0, 1000 ]
But for the life of me I can't assign the names to the list items - any
suggestions?
Below is what I already have - any comments on things I don't really need
to do as well in terms of creating extra string objects etc are also
helpful.
Many thanks
Tom
==EXTRACT=
SEXP typeStr, volumeStr, priceStr, typeValStr;
SEXP priceList;
// create main list of vectors (unspecific items )
PROTECT( priceList = allocVector( VECSXP, 3 ) );
// for each item create a label and attach value
PROTECT( typeValStr = allocVector( STRSXP, 1 ) );
SET_STRING_ELT( typeValStr, 0,
mkChar( getPriceDataTypeAsString( p.getData().getType() ).c_str() ) );
SET_STRING_ELT( priceList, 0, typeValStr) ;
SEXP priceSXP;
PROTECT( priceSXP = allocVector( REALSXP, 1) );
REAL(priceSXP)[0] = p.getData().getPrice();
SET_VECTOR_ELT( priceList, 1, priceSXP);
SEXP volumeSXP;
PROTECT( volumeSXP = allocVector( REALSXP, 1 ) );
REAL(volumeSXP)[0] = p.getData().getVolume();
SET_VECTOR_ELT( priceList, 2, volumeSXP);
WORKS UP TO HERE*
// add the names of the list items (type,price,volume)
SEXP dimnames;
PROTECT( dimnames = allocVector( VECSXP, 3 ) );
// first create string objects
PROTECT( typeStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( typeStr, 0, mkChar("type") );
PROTECT( priceStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( priceStr, 0, mkChar("price") );
PROTECT( volumeStr = allocVector( STRSXP,1 ) );
SET_STRING_ELT( volumeStr, 0, mkChar("volume") );
// assign string objects to vector
SET_VECTOR_ELT( dimnames, 0, typeStr );
SET_VECTOR_ELT( dimnames, 1, priceStr);
SET_VECTOR_ELT( dimnames, 2, volumeStr );
// assign vector to original list of data
setAttrib( priceList, R_DimNamesSymbol, dimnames ); <- I think this
is wrong but I don;t know what it should be
===END EXTRACT===
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Manipulating R lists in C
Thank you so much!! - that works now.
Tom
On Fri, 17 Nov 2006 14:40:38 -, Roger Bivand <[EMAIL PROTECTED]>
wrote:
> On Fri, 17 Nov 2006, Tom McCallum wrote:
>
>> Hi,
>>
>> I have been studying the R manual on lists but cannot seem to create a
>> simple R list in C - I keep on getting "'dimnames' applied to non-array"
>> whenever I attempt to assign names to the list elements:
>
> Maybe:
>
>setAttrib( priceList, R_NamesSymbol, dimnames );
>
> why should a list have dimnames?
>
> In addition, your dimnames is a list, and likely ought to be a character
> vector. That way you can get away with many fewer PROTECT().
>
> Roger
>
>>
>> Wanted output a list structure something like
>> [ type="Bid", price=2.0, volume=1000 ]
>>
>> I can get up to a list of
>> [ "Bid2, 2.0, 1000 ]
>>
>> But for the life of me I can't assign the names to the list items - any
>> suggestions?
>>
>> Below is what I already have - any comments on things I don't really
>> need
>> to do as well in terms of creating extra string objects etc are also
>> helpful.
>>
>> Many thanks
>>
>> Tom
>>
>>
>> ==EXTRACT=
>>
>>
>>SEXP typeStr, volumeStr, priceStr, typeValStr;
>>SEXP priceList;
>>
>>// create main list of vectors (unspecific items )
>>PROTECT( priceList = allocVector( VECSXP, 3 ) );
>>
>>// for each item create a label and attach value
>>PROTECT( typeValStr = allocVector( STRSXP, 1 ) );
>>SET_STRING_ELT( typeValStr, 0,
>> mkChar( getPriceDataTypeAsString( p.getData().getType() ).c_str() ) );
>>SET_STRING_ELT( priceList, 0, typeValStr) ;
>>
>>SEXP priceSXP;
>>PROTECT( priceSXP = allocVector( REALSXP, 1) );
>>REAL(priceSXP)[0] = p.getData().getPrice();
>>SET_VECTOR_ELT( priceList, 1, priceSXP);
>>
>>SEXP volumeSXP;
>>PROTECT( volumeSXP = allocVector( REALSXP, 1 ) );
>>REAL(volumeSXP)[0] = p.getData().getVolume();
>>SET_VECTOR_ELT( priceList, 2, volumeSXP);
>>
>>WORKS UP TO HERE*
>>
>>// add the names of the list items (type,price,volume)
>>SEXP dimnames;
>>PROTECT( dimnames = allocVector( VECSXP, 3 ) );
>>
>>// first create string objects
>>PROTECT( typeStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( typeStr, 0, mkChar("type") );
>>
>>PROTECT( priceStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( priceStr, 0, mkChar("price") );
>>
>>PROTECT( volumeStr = allocVector( STRSXP,1 ) );
>>SET_STRING_ELT( volumeStr, 0, mkChar("volume") );
>>
>>// assign string objects to vector
>>SET_VECTOR_ELT( dimnames, 0, typeStr );
>>SET_VECTOR_ELT( dimnames, 1, priceStr);
>>SET_VECTOR_ELT( dimnames, 2, volumeStr );
>>
>>// assign vector to original list of data
>>setAttrib( priceList, R_DimNamesSymbol, dimnames ); <- I think
>> this
>> is wrong but I don;t know what it should be
>>
>> ===END EXTRACT===
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Data table in C
After getting one list done, I am now struggling to form a data frame in C.
I tried to do a list of lists which gives me :
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6718
$[[3]]
[1] 3e+06
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6717
$[[3]]
[1] 5e+06
$
$[[1]]
[1] "BID"
$[[2]]
[1] 0.6717
$[[3]]
[1] 1720
and then as.data.frame them in R but this gives me
> print(l);
X0.type X0.price X0.volume X1.type X1.price X1.volume X2.type X2.price
1 BID 0.6723 3e+06 BID 0.6722 5e+06 BID 0.67195
X2.volume X3.type X3.price X3.volume X4.type X4.price X4.volume X5.type
1 1940 BID 0.6723 3e+06 BID 0.6722 5e+06 BID
X5.price X5.volume X6.type X6.price X6.volume X7.type X7.price X7.volume
1 0.6723 3e+06 BID 0.6723 3e+06 BID 0.67195 1940
X8.type X8.price X8.volume X9.type X9.price X9.volume X10.type X10.price
1 BID 0.6723 3e+06 BID 0.67215 1e+07 BID0.6723
X10.volume X11.type X11.price X11.volume X12.type X12.price X12.volume
1 5e+06 BID 0.67215 1e+07 BID0.6723 3e+06
and so on.
Is the only way in C to do this or is there a better way of creating a 2
dimensional data frame with names columns? I could not find a
"data.frame" object so I assume one has to use lists but I can't see how
to get a 3 column list as the example below shows:
a b d
1 1 4 7
2 2 5 8
3 3 6 9
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load
To answer my own question - you can use DllMain with Rwin_fpset() to get
around this error message.
Am still struggling though as it crashes when it tries to call a function
in the wrapped DLL - any ideas on how to debug this?
Hope this is of help to some one
Tom
On Tue, 21 Nov 2006 17:30:56 -, Tom McCallum
<[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> Now I know there is information on this in the help files - which I have
> read. I am very close to implementing this but can't quite get how to
> remove this final hurdle.
>
> I have a DLL called "X.DLL" which I have no original code for, just the
> DLL.
> I have created a wrapper C file for the calls in X.DLL, and have
> successfully (I think) created a wrapper DLL for X called, lets say,
> WRAPX.DLL.
>
> On performing:
>
>> dyn.load("WRAPX.dll")
>
> in the Rgui terminal, I then received this warning:
>
> Warning message:
> DLL attempted to change FPU control word from 8001f to 9001f
>
> Getting rid of this error was part of the reason for writing WRAPX.DLL,
> as
> X.DLL seems to play about with this register.
>
> So having another look at the manual entry, I then used the function
> Rwin_fpset() (in gnuwin32/extra.c) to reset the FPU control register when
> I leave all the functions in WRAPX.DLL. But the problem persists. In
> the
> Delphi example in the manual, which I have put at the end of this
> message,
> ( and I have never programmed in Delphi before so I am guessing ) there
> is
> the opportunity on loading the dynamic library to set this register, but
> I
> am wondering where in the C file I can put this command so that when
> dyn.load is called it is not upset by X.DLL changing this register. I
> think I need the following passage of play to occur:
>
> USER : > dyn.load("WRAPX.DLL");
> R : Calls WRAPX.DLL
> WRAPX.DLL : WRAPX.DLL initialises X.DLL which interferes with FPU
> register
> WRAPX.DLL : Calls Rwin_fpset() to reset FPU register
> R : R tests FPU register and is happy
> USER : Sees "Success library is loaded!" or something to that effect
> :)
>
> Any ideas on how to achieve this?
>
> Many thanks
>
> Tom
>
> DELPHI CODE=
>
> procedure Rwin_fpset; cdecl; external 'R.dll';
>
> function Get8087CW:word;
> begin
>asm
> fstcw result
>end;
> end;
>
> begin
>Rwin_fpset(); <== these lines I think is called on
> loading
> of the DLL to reset the register
>Set8087CW(Get8087CW); <
> end.
>
> ===END DELPHI CODE=
>
>
>
> --
> Dr. Thomas McCallum
> Systems Architect,
> Level E Limited
> ETTC, The King's Buildings
> Mayfield Road,
> Edinburgh EH9 3JL, UK
> Work +44 (0) 131 472 4813
> Fax: +44 (0) 131 472 4719
> http://www.levelelimited.com
> Email: [EMAIL PROTECTED]
>
> Level E is a limited company incorporated in Scotland. The
> c...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ralloc clash
Hi everyone,
Have been trying to include windows.h (from MinGW) and R.h into a package
and have found that Ralloc is coming up as a clash no matter which include
ordering I use. In windows it has 2 arguments and is defined in objidl.h
and in R.h it is 3 arguments. Any ideas of how to work round this? Have
checked the web and have not seen anyone else comment on this.
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ralloc clash
Thank you for your reply. My mistake - I meant Realloc (missed the 'e').
This morning I reinstalled MinGW with all the patches suggested by the
Install R on Windows Help page, including w32api-3.7, just to make sure
all was as it should be. I have put
#define WIN32_LEAN_AND_MEAN
at the top of my cpp file (which I did not know about so that was
interesting) but it is still saying there is a conflict between Realloc in
objidl.h and windows.h. Interesting I had a C file which I _did_ manage
to compile with the R.h and windows.h file in without this error coming
up. Could there be something going on with g++ that gcc is ignoring? I
am no sure it iss a clash now as I cannot find Realloc in the R includes
but below is some output I have gathered which may be of assistance.
In objidl.h (line 532):
STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
In R.h it has the solitary line:
/* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
Can only find a R_alloc but no Realloc.
==ERROR MSG OUTPUT==
$ R CMD SHLIB callcdeclcall.cpp
making callcdeclcall.d from callcdeclcall.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
from callcdeclcall.cpp:4:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
macro "Realloc" requires 3 arguments, but only 2 given
make: *** [callcdeclcall.d] Error 1
==END ERROR MSG OUTPUT==
Headers in CPP file are:
#include
#include
#include
#include
#include
Thanks,
Tom
On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> Where exactly did you get windows.h from? The recommended source is
> w32api-3.7.tar.gz, and there is no Ralloc in any of its header files,
> including objidl.h.
>
> BTW, do you know about defining WIN32_LEAN_AND_MEAN when including
> windows.h? If not, it is worth finding out about.
>
>
> On Wed, 22 Nov 2006, Tom McCallum wrote:
>
>> Hi everyone,
>>
>> Have been trying to include windows.h (from MinGW) and R.h into a
>> package
>> and have found that Ralloc is coming up as a clash no matter which
>> include
>> ordering I use. In windows it has 2 arguments and is defined in
>> objidl.h
>> and in R.h it is 3 arguments. Any ideas of how to work round this?
>> Have
>> checked the web and have not seen anyone else comment on this.
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ralloc clash
But from R_ext/RS.h you have (my comments are given by <-- some text):
BEGIN
EXTRACT
#ifndef STRICT_R_HEADERS
<-- fair enough this is defined but it
ends ...
#define R_PROBLEM_BUFSIZE 4096
/* Parentheses added for FC4 with gcc4 and -D_FORTIFY_SOURCE=2 */
#define PROBLEM {char
R_problem_buf[R_PROBLEM_BUFSIZE];(sprintf)(R_problem_buf,
#define MESSAGE {char
R_problem_buf[R_PROBLEM_BUFSIZE];(sprintf)(R_problem_buf,
#define ERROR ),error(R_problem_buf);}
#define RECOVER(x) ),error(R_problem_buf);}
#define WARNING(x) ),warning(R_problem_buf);}
#define LOCAL_EVALUATOR /**/
#define NULL_ENTRY /**/
#define WARNWARNING(NULL)
#endif
<-- ifndef clause ends here
/* S Like Memory Management */
extern void *R_chk_calloc(size_t, size_t);
extern void *R_chk_realloc(void *, size_t);
extern void R_chk_free(void *);
#define Calloc(n, t) (t *) R_chk_calloc( (size_t) (n), sizeof(t) )
#define Realloc(p,n,t) (t *) R_chk_realloc( (void *)(p), (size_t)((n) *
sizeof(t)) ) <-- This is still defined therefore, is it not?
/* S-PLUS 3.x but not 5.x NULLs the pointer in the following */
#ifndef STRICT_R_HEADERS
#define Free(p)(R_chk_free( (void *)(p) ), (p) = NULL)
#endif
#define R_Free(p) (R_chk_free( (void *)(p) ), (p) = NULL)
#define Memcpy(p,q,n) memcpy( p, q, (size_t)( (n) * sizeof(*p) ) )
END
EXTRACT
The STRICT_R_HEADERS does not go around the Realloc function so even with
STRICT_R_HEADERS defined the problem persists.
To test I placed "#define STRICT_R_HEADERS" at the top of my single cpp
file before all the include lines as I am not sure how to pass the -D
function through to the g++ when doing R CMD SHLIB - would putting it in
one of the PKG_ environment variables work - if so which?
Tom
On Thu, 23 Nov 2006 11:13:44 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> Realloc is defined in R_ext/RS.h, and only if STRICT_R_HEADERS is not
> defined. This *is* documented in 'Writing R Extensions'.
>
> On Thu, 23 Nov 2006, Tom McCallum wrote:
>
>> Thank you for your reply. My mistake - I meant Realloc (missed the
>> 'e').
>> This morning I reinstalled MinGW with all the patches suggested by the
>> Install R on Windows Help page, including w32api-3.7, just to make sure
>> all was as it should be. I have put
>>
>> #define WIN32_LEAN_AND_MEAN
>>
>> at the top of my cpp file (which I did not know about so that was
>> interesting) but it is still saying there is a conflict between Realloc
>> in
>> objidl.h and windows.h. Interesting I had a C file which I _did_ manage
>> to compile with the R.h and windows.h file in without this error coming
>> up. Could there be something going on with g++ that gcc is ignoring? I
>> am no sure it iss a clash now as I cannot find Realloc in the R includes
>> but below is some output I have gathered which may be of assistance.
>>
>> In objidl.h (line 532):
>> STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
>>
>> In R.h it has the solitary line:
>> /* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
>> Can only find a R_alloc but no Realloc.
>>
>> ==ERROR MSG OUTPUT==
>> $ R CMD SHLIB callcdeclcall.cpp
>> making callcdeclcall.d from callcdeclcall.cpp
>> In file included from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
>> from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
>> from
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
>> from callcdeclcall.cpp:4:
>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
>> macro "Realloc" requires 3 arguments, but only 2 given
>> make: *** [callcdeclcall.d] Error 1
>> ==END ERROR MSG OUTPUT==
>>
>> Headers in CPP file are:
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> Thanks,
>>
>> Tom
>>
>>
>> On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Where exactly did you get windows.h from? The recommended source is
>>> w32api-3.7.tar.gz, and there is no Ralloc in any of
Re: [Rd] Ralloc clash
Thank you that did the job.
Tom
On Thu, 23 Nov 2006 13:06:29 -, Prof Brian Ripley
<[EMAIL PROTECTED]> wrote:
> On Thu, 23 Nov 2006, Prof Brian Ripley wrote:
>
>> Realloc is defined in R_ext/RS.h, and only if STRICT_R_HEADERS is not
>> defined. This *is* documented in 'Writing R Extensions'.
>
> That was the general intention, but seems not to cover this example.
> Howver,
>
> #include
> #undef Realloc
> #define R_Realloc(p,n,t) (t *) R_chk_realloc( (void *)(p), (size_t)((n)
> * sizeof(t)) )
> #include
>
> seems to work.
>
>
>> On Thu, 23 Nov 2006, Tom McCallum wrote:
>>
>>> Thank you for your reply. My mistake - I meant Realloc (missed the
>>> 'e').
>>> This morning I reinstalled MinGW with all the patches suggested by the
>>> Install R on Windows Help page, including w32api-3.7, just to make sure
>>> all was as it should be. I have put
>>> #define WIN32_LEAN_AND_MEAN
>>> at the top of my cpp file (which I did not know about so that was
>>> interesting) but it is still saying there is a conflict between
>>> Realloc in
>>> objidl.h and windows.h. Interesting I had a C file which I _did_
>>> manage
>>> to compile with the R.h and windows.h file in without this error coming
>>> up. Could there be something going on with g++ that gcc is ignoring?
>>> I
>>> am no sure it iss a clash now as I cannot find Realloc in the R
>>> includes
>>> but below is some output I have gathered which may be of assistance.
>>> In objidl.h (line 532):
>>> STDMETHOD_(void*,Realloc)(THIS_ void*,ULONG) PURE;
>>> In R.h it has the solitary line:
>>> /* for PROBLEM ... Calloc, Realloc, Free, Memcpy, F77_ */
>>> Can only find a R_alloc but no Realloc.
>>> ==ERROR MSG OUTPUT==
>>> $ R CMD SHLIB callcdeclcall.cpp
>>> making callcdeclcall.d from callcdeclcall.cpp
>>> In file included from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:73,
>>> from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
>>> from
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:111,
>>> from callcdeclcall.cpp:4:
>>> c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objidl.h:532:45:
>>> macro "Realloc" requires 3 arguments, but only 2 given
>>> make: *** [callcdeclcall.d] Error 1
>>> ==END ERROR MSG OUTPUT==
>>> Headers in CPP file are:
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> Thanks,
>>> Tom
>>> On Wed, 22 Nov 2006 21:21:15 -, Prof Brian Ripley
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>> Where exactly did you get windows.h from? The recommended source is
>>>> w32api-3.7.tar.gz, and there is no Ralloc in any of its header files,
>>>> including objidl.h.
>>>> BTW, do you know about defining WIN32_LEAN_AND_MEAN when including
>>>> windows.h? If not, it is worth finding out about.
>>>> On Wed, 22 Nov 2006, Tom McCallum wrote:
>>>>
>>>>> Hi everyone,
>>>>> Have been trying to include windows.h (from MinGW) and R.h into a
>>>>> package
>>>>> and have found that Ralloc is coming up as a clash no matter which
>>>>> include
>>>>> ordering I use. In windows it has 2 arguments and is defined in
>>>>> objidl.h
>>>>> and in R.h it is 3 arguments. Any ideas of how to work round this?
>>>>> Have
>>>>> checked the web and have not seen anyone else comment on this.
>>>>
>>>
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Floating point maths in R
Hi,
I am not sure if this is just me using R (R-2.3.1 and R-2.4.0) in the
wrong way or if there is a more serious bug. I was having problems
getting some calculations to add up so I ran the following tests:
> (2.34567 - 2.0) == 0.34567 <--- should be true
[1] FALSE
> (2.23-2.00) == 0.23 <--- should be true
[1] FALSE
> 4-2==2
[1] TRUE
> (4-2)==2
[1] TRUE
> (4.0-2)==2
[1] TRUE
> (4.0-2.0)==2
[1] TRUE
> (4.0-2.0)==2.0
[1] TRUE
> (4.2-2.2)==2.0
[1] TRUE
> (4.20-2.20)==2.00
[1] TRUE
> (4.23-2.23)==2.00 <--- should be true
[1] FALSE
> (4.230-2.230)==2.000 <--- should be true
[1] FALSE
> (4.230-2.230)==2.00 <--- should be true
[1] FALSE
> (4.230-2.23)==2.00 <--- should be true
[1] FALSE
I have tried these on both 64 and 32-bit machines. Surely R should be
able to do maths to 2 decimal places and be able to test these simple
expressions? The problem occurs as in the 16th decimal place junk is
being placed by the FPU it seems. I have also tried:
> (4.2300-2.230) == 2
[1] FALSE
> a <- (4.2300-2.230)
> a == 2
[1] FALSE
> (4.2300-2.230) == 2.
[1] FALSE
> (4.2300-2.230) == 2.0004 <-- correct
> when add 16th decimal place to 4
[1] TRUE
> (4.2300-2.230) == 2.00043 <-- any
> values after the 16th decimal place mean that the expression is true
[1] TRUE
> (4.2300-2.230) == 2.000435
[1] TRUE
Also :
> (4.2300-2.230) == 2.0001
[1] FALSE
> (4.2300-2.230) == 2.0003
[1] TRUE
> (4.2300-2.230) == 2.0004
[1] TRUE
> (4.2300-2.230) == 2.0005
[1] TRUE
> (4.2300-2.230) == 2.0006 <-- 3,5 I
> can understand being true if rounding occurring, but 6?
[1] TRUE
> (4.2300-2.230) == 2.0007
[1] FALSE
> (4.2300-2.230) == 2.0008
[1] FALSE
> (4.2300-2.230) == 2.0009
[1] FALSE
> (4.2300-2.230) == 2.0010
This is an example of junk being added in the FPU
> formatC(a, digits=20)
[1] "2.0004441"
I don't know if this is just a formatC error when using more than 16
decimal places or if this junk is what is stopping the equality from being
true:
> formatC(a, digits=16)
[1] "2"
> formatC(a, digits=17) <-- 16 decimal places, 17 significant figures
> shown
[1] "2.0004" <-- the problem is the 4 at the end
Obviously the bytes are divided between the exponent and mantissa in
16-16bit share it seems, but this doesn't account for the 16th decimal
place behaviour does it?
If any one has a work around or reason why this should occur it would be
useful to know.
what I would like is to be able to do sums such as (2.3456 - 2 ) == 0.3456
and get a sensible answer - any suggestions? Currently the only way is
for formatC the expression to a known number of decimal places - is there
a better way?
Many thanks
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Floating point maths in R
Many thanks for pointing that out.
Tom
On Sat, 09 Dec 2006 13:48:06 -, Peter Dalgaard
<[EMAIL PROTECTED]> wrote:
> Tom McCallum wrote:
>> Hi,
>>
>> I am not sure if this is just me using R (R-2.3.1 and R-2.4.0) in the
>> wrong way or if there is a more serious bug. I was having problems
>> getting some calculations to add up so I ran the following tests:
>>
>>
> Please read FAQ 7.31 and the reference therein.
>
> http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
>
> (short answer: You can not represent thirds exactly in decimal nor
> tenths in binary.)
>>> (2.34567 - 2.0) == 0.34567 <--- should be true
>>>
>> [1] FALSE
>>
>>> (2.23-2.00) == 0.23 <--- should be true
>>>
>> [1] FALSE
>>
>>> 4-2==2
>>>
>> [1] TRUE
>>
>>> (4-2)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2.0)==2
>>>
>> [1] TRUE
>>
>>> (4.0-2.0)==2.0
>>>
>> [1] TRUE
>>
>>> (4.2-2.2)==2.0
>>>
>> [1] TRUE
>>
>>> (4.20-2.20)==2.00
>>>
>> [1] TRUE
>>
>>> (4.23-2.23)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.230)==2.000 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.230)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>>> (4.230-2.23)==2.00 <--- should be true
>>>
>> [1] FALSE
>>
>> I have tried these on both 64 and 32-bit machines. Surely R should be
>> able to do maths to 2 decimal places and be able to test these simple
>> expressions? The problem occurs as in the 16th decimal place junk is
>> being placed by the FPU it seems. I have also tried:
>>
>>
>>> (4.2300-2.230) == 2
>>>
>> [1] FALSE
>>
>>> a <- (4.2300-2.230)
>>> a == 2
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0004 <--
>>> correct when add 16th decimal place to 4
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.00043 <--
>>> any values after the 16th decimal place mean that the expression is
>>> true
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.000435
>>>
>> [1] TRUE
>>
>> Also :
>>
>>
>>> (4.2300-2.230) == 2.0001
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0003
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0004
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0005
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0006 <-- 3,5
>>> I can understand being true if rounding occurring, but 6?
>>>
>> [1] TRUE
>>
>>> (4.2300-2.230) == 2.0007
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0008
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0009
>>>
>> [1] FALSE
>>
>>> (4.2300-2.230) == 2.0010
>>>
>>
>>
>> This is an example of junk being added in the FPU
>>
>>> formatC(a, digits=20)
>>>
>> [1] "2.0004441"
>>
>> I don't know if this is just a formatC error when using more than 16
>> decimal places or if this junk is what is stopping the equality from
>> being true:
>>
>>
>>> formatC(a, digits=16)
>>>
>> [1] "2"
>>
>>> formatC(a, digits=17) <-- 16 decimal places, 17 significant figures
>>> shown
>>>
>> [1] "2.0004" <-- the problem is the 4 at the end
>>
>> Obviously the bytes are divided between the exponent and mantissa in
>> 16-16bit share it seems, but this doesn't account for the 16th decimal
>> place behaviour does it?
>>
>> If any one has a work around or reason why this should occur it would
>> be useful to know.
>>
>> what I would like is to be able to do sums such as (2.3456 - 2 ) ==
>> 0.3456 and get a sensible answer - any suggestions? Currently the
>> only way is for formatC the expression to a known number of decimal
>> places - is there a better way?
>>
>> Many thanks
>>
>> Tom
>>
>>
>>
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The c...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
