Re: [Rd] Call R From VC++

[TB]

Shilpi,

shilpi harpavat  wrote:

> I want to write an independent C++ application that
> can call any R functions and output it as an
> c++object.
> I tried to use The documentation for Linking R DLL
> with VC++ But with no success.
> When I link R.dll it says Invalid or corrupt file
> Any help greatly aprrciated.

An alternative to directly accessing R.dll from VC++
is to use COM. See http://cran.r-project.org/contrib/extra/dcom/
for a (D)COM server or use the package rcom for another (D)COM
server implementing the same COM interfaces.

Thomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Questions on how to handle R objects in C

[Wen Wan]

Hello,

I have a question on how to handle R objects in C. I have spent a lot of time 
on it but I still can not figure it out.

My situation is as following. I have already had C++ code for a genetic 
algorithm. The genetic algorithm need function evaluations. And the function I 
am going to use includes matrix inverse and other matrix manipulation. As you 
know, doing matrix manipulation is hard by C++ but is much easier by R. What I 
want to do is to use R to call C subroutine (genetic algorithm), but in the C 
code, let R help C do matrix manipulation. So I need use .Call instead of .C. 
I got some information on it from website 
(http://lib.stat.cmu.edu/R/CRAN/doc/manuals/R-exts.pdf), but it is hard to 
read and understand. I also read the introduction to the .C interface to R 
which you told me, but it is not the same situation as what I have.

I have another problem. I don’t know how to put a lot of C functions together 
when we use .C or .Call. This is different from the C code itself. In C code 
itself, we have main() function, list several functions’ definitions outside 
of the main(), before the main(), we need add those functions’ declaration. I 
don’t know how to range those functions if we want to use R to call C.

If all of these questions need take you a lot time to explain, would you 
please give me some examples which you used before. Thank you very much.

Best wishes,

Wen


Wen Wan
Department of Statistics
Virginia Polytechnic University
403-D Hutcheson Hall
Blacksburg, VA 24061-0439
Email: [EMAIL PROTECTED]
Phone:(540)922-2496
Fax:   (540) 231-3863

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] S4 Methods with large numbers of args using memory

[Seth Falcon]

[This is probably more appropriate for R-devel so I'm responding
there]

Joseph Wang <[EMAIL PROTECTED]> writes:

> Thanks all to the people on the r-help list for the backtick help.
>
> I've run into another problem.  With my SWIG C++ wrapper for R, I'm finding 
> that S4 generic functions with large numbers of argument (such as 10 or 11) 
> seem to be taking up a lot of memory especially when a lot of the arguments 
> are set to missing.
>
> This happens because I'm generating S4 methods to wrapper C++ functions with 
> optional arguments.  Each wrapper can take several meg of heap causing my R 
> program to quickly run out of heap memory.
>
> Any ideas as to what the problem is and any possible way of working
> around it?

I think the issue is related to the overhead of storing strings and
possibly language objects in R.  The memory used by a couple of large
setMethod calls is striking.

As for work arounds, I think you can make things better if it is the
case that you don't actually want to do dispatch on the possibly
missing arguments.  For example, if the signature is:

f(a, b, o1, o2, o3)

Where you want to dispatch on 'a' and 'b' and where o1, ..., o3 are
optional.  In that case you can

* Use a parameter object.  For the example above, you'd have slots o1,
  ..., o3 and the signature would become f(a, b, params).  Default
  values can be specified in the prototype for the param object class
  definition.

* Put args after '...'.  So you would have something like:

setGeneric("f", function(a, b, ..., o1=1, o2=2, o3=3) standardGeneric("f"))

  Partial matching won't work for these args if you do this, but it
  can be a nice way to provide optional named args common to all
  methods of a generic function, but for which you do not ever want to
  do dispatch.

+ seth

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] install.packages() does not warn when 'lib' arg is missing on Linux or Windows

[Herve Pages]

Hello,

Man page for 'install.packages' says that if the 'lib' arg is missing,
then it "defaults to '.libPaths()[1]' with a warning".
But, given the 'install.packages' source code, it seems that this warning
is issued only when 'length(.libPaths()) > 1'.
So typically, this warning will appear on Mac OS X but not on a Linux
or Windows systems with default settings.
On my Mac OS X system:

 > .libPaths()
[1] "/Users/biocbuild/Library/R/Library"
[2] "/Library/Frameworks/R.Framework/Versions/2.3/Resources/library"

but on my Linux system:

 > .libPaths()
[1] "/home/hpages/arch/x86_64/R-2.3.1/library"

I'm using R-2.3.1 on both systems.
Best,


H.

-- 

Hervé Pagès
E-mail: [EMAIL PROTECTED]
 Phone: (206) 667-5791
   Fax: (206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] install.packages() does not warn when 'lib' arg is missing on Linux or Windows

[Prof Brian Ripley]

On Thu, 8 Jun 2006, Herve Pages wrote:

> Hello,
>
> Man page for 'install.packages' says that if the 'lib' arg is missing,
> then it "defaults to '.libPaths()[1]' with a warning".
> But, given the 'install.packages' source code, it seems that this warning
> is issued only when 'length(.libPaths()) > 1'.
> So typically, this warning will appear on Mac OS X but not on a Linux
> or Windows systems with default settings.

Yes, and what is the problem with that?

> On my Mac OS X system:
>
> > .libPaths()
>[1] "/Users/biocbuild/Library/R/Library"
>[2] "/Library/Frameworks/R.Framework/Versions/2.3/Resources/library"
>
> but on my Linux system:
>
> > .libPaths()
>[1] "/home/hpages/arch/x86_64/R-2.3.1/library"
>
> I'm using R-2.3.1 on both systems.
> Best,
>
>
> H.
>
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] install.packages("C", dep=TRUE) does not always install indirect dependencies

[Herve Pages]

Hello again,

I've found another issue with 'install.packages'.
'install.packages("C", dep=TRUE)' will "fail" when the 2 following
conditions are satisfied:
  - Package C depends on B which in turns depends on A but
the Depends field in C doesn't list A.
  - Package B is already installed but not package A (e.g.
the user did 'install.packages("B", dep=FALSE)').
Then 'install.packages("C", dep=TRUE)' will not install A.
May be this is the desired behavior, I don't know. Personally, I would
think of 'install.packages("C", dep=TRUE)' as a reliable way to get every
packages that C directly or indirectly relies on installed.

Best,

H.

-- 

Hervé Pagès
E-mail: [EMAIL PROTECTED]
 Phone: (206) 667-5791
   Fax: (206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] install.packages() does not warn when 'lib' arg is missing on Linux or Windows

[Herve Pages]

Prof Brian Ripley wrote:
> On Thu, 8 Jun 2006, Herve Pages wrote:
>
>> Man page for 'install.packages' says that if the 'lib' arg is missing,
>> then it "defaults to '.libPaths()[1]' with a warning".
>> But, given the 'install.packages' source code, it seems that this 
>> warning
>> is issued only when 'length(.libPaths()) > 1'.
>
> Yes, and what is the problem with that?
Since current behaviour is not in sync with documentation then
IMHO it's either a documentation bug or an implementation bug.
Best,

H.

-- 

Hervé Pagès
E-mail: [EMAIL PROTECTED]
 Phone: (206) 667-5791
   Fax: (206) 667-1319

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] install.packages("C", dep=TRUE) does not always install indirect dependencies

[Duncan Murdoch]

On 6/8/2006 3:31 PM, Herve Pages wrote:
> Hello again,
> 
> I've found another issue with 'install.packages'.
> 'install.packages("C", dep=TRUE)' will "fail" when the 2 following
> conditions are satisfied:
>   - Package C depends on B which in turns depends on A but
> the Depends field in C doesn't list A.
>   - Package B is already installed but not package A (e.g.
> the user did 'install.packages("B", dep=FALSE)').
> Then 'install.packages("C", dep=TRUE)' will not install A.
> May be this is the desired behavior, I don't know. Personally, I would
> think of 'install.packages("C", dep=TRUE)' as a reliable way to get every
> packages that C directly or indirectly relies on installed.

This seems rather unreasonable.  If a user asked not to install B's 
dependencies, and A is not listed as a dependency of C, then I don't 
think a request to install C and its dependencies should install A.

Perhaps the installation of B without dependencies was a mistake?  I 
think an argument could be made that dependencies=TRUE should be the 
default (as it is when using the corresponding menu item in the Windows 
GUI).

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] NAs in unsplit factor

[Jeff Enos]

R-devel,

Below is a simple example calling split and unsplit on a numeric
vector of length 2 where 'f' is c(1,NA).

> unsplit(split(c(1,2), c(1,NA)), c(1,NA))
[1] 1 0

I noticed that the call to vector in unsplit gives us 0 as the 2nd
element of the result.

Is this the intended result, as opposed to NA?

Thanks for your help,

Jeff

-- 
Jeff Enos
Kane Capital Management
[EMAIL PROTECTED]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] install.packages() does not warn when 'lib' arg is missing on Linux or Windows

[Simon Urbanek]

Herve,

On Jun 8, 2006, at 9:08 PM, Herve Pages wrote:

> Man page for 'install.packages' says that if the 'lib' arg is missing,
> then it "defaults to '.libPaths()[1]' with a warning".

Where are you quoting from? I read (R 2.3.1):

install.packages can be used to install new packages/bundles. It  
takes a vector of names and a destination library, downloads the  
packages from the repositories and installs them. (If the library is  
omitted it defaults to the first directory in .libPaths(), with a  
warning if there is more than one.)

and that description is correct.


> But, given the 'install.packages' source code, it seems that this  
> warning is issued only when 'length(.libPaths()) > 1'.

This is what the man page says ...


> So typically, this warning will appear on Mac OS X but not on a  
> Linux or Windows systems with default settings.

... and neither on Mac OS X with default settings.


> On my Mac OS X system:
>
>> .libPaths()
> [1] "/Users/biocbuild/Library/R/Library"

^^ - this is your custom setting, it is not the default

> [2] "/Library/Frameworks/R.Framework/Versions/2.3/Resources/ 
> library"
>

The default on OS X is

 > .libPaths()
[1] "/Library/Frameworks/R.framework/Resources/library"
 >

in the shell and

 > .libPaths()
[1] "/Library/Frameworks/R.framework/Versions/2.3/Resources/library"
 >

in the GUI (since v1.16).

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] NAs in unsplit factor

[François Pinard]

[Jeff Enos]

>Below is a simple example calling split and unsplit on a numeric
>vector of length 2 where 'f' is c(1,NA).

>> unsplit(split(c(1,2), c(1,NA)), c(1,NA))
>[1] 1 0

>I noticed that the call to vector in unsplit gives us 0 as the 2nd
>element of the result.

>Is this the intended result, as opposed to NA?

?unsplit says:

  'unsplit' reverses the effect of 'split'.

and later explains:

  'unsplit' returns a vector for which 'split(x, f)' equals 'value'

So some may argue that, while not necessarily intended, that this is at 
least not unintended :-).  Yet, why "0" is chosen here, among a myriad 
of possibilities?  "NA", as you suggest, might be a more neutral choice.

-- 
François Pinard   http://pinard.progiciels-bpi.ca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] install.packages("C", dep=TRUE) does not always install indirect dependencies

[Seth Falcon]

Duncan Murdoch <[EMAIL PROTECTED]> writes:
>> conditions are satisfied:
>>   - Package C depends on B which in turns depends on A but
>> the Depends field in C doesn't list A.
>>   - Package B is already installed but not package A (e.g.
>> the user did 'install.packages("B", dep=FALSE)').
>> Then 'install.packages("C", dep=TRUE)' will not install A.
>> May be this is the desired behavior, I don't know. Personally, I would
>> think of 'install.packages("C", dep=TRUE)' as a reliable way to get every
>> packages that C directly or indirectly relies on installed.
>
> This seems rather unreasonable.  If a user asked not to install B's 
> dependencies, and A is not listed as a dependency of C, then I don't 
> think a request to install C and its dependencies should install A.

I see your point, but the unreasonable-ness kinda works both ways: If
a user asked to install C and _all_ its dependencies, then I think
that request should do that :-)

> Perhaps the installation of B without dependencies was a mistake?  I 
> think an argument could be made that dependencies=TRUE should be the 
> default (as it is when using the corresponding menu item in the Windows 
> GUI).

Installing dependencies seems like a reasonable default to me.  Having
the flexibility to not install dependencies is nice, but I imagine for
a majority of users they install a package in order to use it, and
mostly you can't use a package unless you have its dependencies
installed.

+ seth

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel