Re: [Rd] Hello! I got error in C - R
Dear Ick Hoon Jin,
Your problem is probably due to a misspecification in memory allocation
within your C code. To solve this you can:
* check by yourself whenever there is C memory allocation - by the
way I think it's best to use R memory allocation i.e. R_alloc
* use valgrind (see Writing R extension for this) as you're under
Linux and this will give you some guidance to find where the
problem is.
Best,
Mathieu
Le vendredi 03 avril 2009 à 03:47 +0200, kent...@stat.tamu.edu a écrit :
> Hello,
> My name is Ick Hoon Jin and I am Ph. D. student in Texas A & M Univ..
> When I run the C embedded in R in the Linux system, I confront the
> following error after 6,000 iteration. By googling I found this error is
> from the problem in C.
>
> *** caught segfault ***
> address (nil), cause 'memory not mapped'
>
> My C code is following:
>
> ---
> #include
> #include
> #include
> #include
> #include
>
> #define Min(X,Y) ((X) < (Y) ? (X) : (Y))
>
> void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
> *n_para, double *out);
> int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n);
> double Count_Edges(int *X, int n);
> double Cal_GWD(int *X, int n);
> int Cal_Degree(int *M3, int n);
> double Inner_Product( double *vector1, double *vector2, int length);
> int rdtsc();
>
> void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
> *n_para, double *out)
> {
> int i, j, a, k;
> int *M1, *M2;
> M1 = (int *)calloc(*length_X, sizeof(int));
> M2 = (int *)calloc(*length_X, sizeof(int));
>
> for(i = 1; i < *n; i++)
> {
> for(j = 0; j < i; j++)
> {
> for(k = 0; k < *length_X; k++ )
> {
> M1[k] = X[k];
> M2[k] = X[k];
> }
>
> if(X[i * *n + j] == 1)
> {
> M1[i * *n + j] = 0;
> a = MH_Result(theta_new, *n_para, M1, M2, *n);
> if(a == 1)
> {
> X[i * *n + j] = 0;
> }
> }
> else
> {
> M1[i * *n + j] = 1;
> a = MH_Result(theta_new, *n_para, M1, M2, *n);
> if(a == 1)
> {
> X[i * *n + j] = 1;
> }
> }
> }
> }
>
> for(i = 1; i < *n; i++)
> {
> for(j = 0; j < i; j++)
> {
> X[j * *n + i] = 0;
> }
> }
>
> for(i = 0; i < *length_X; i++)
> {
> out[i] = (double)X[i];
> }
>
> free(M1);
> free(M2);
>
> return;
> }
>
> int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n)
> {
> double *M1_STAT, *M2_STAT;
> double pi_Num, pi_Denom, MH_Ratio, v;
>
> M1_STAT = (double *)calloc( n_para, sizeof( double ) );
> M2_STAT = (double *)calloc( n_para, sizeof( double ) );
>
> M1_STAT[0] = Count_Edges(M1, n);
> M2_STAT[0] = Count_Edges(M2, n);
>
> M1_STAT[1] = Cal_GWD(M1, n);
> M2_STAT[1] = Cal_GWD(M2, n);
>
> pi_Num = Inner_Product(theta_new, M1_STAT, n_para);
> pi_Denom = Inner_Product(theta_new, M2_STAT, n_para);
> MH_Ratio = pi_Num - pi_Denom;
>
> srand(rdtsc());
> v = (double)rand() / ( (double)RAND_MAX + (double)1 );
>
> if( log( v ) < Min( 0, MH_Ratio ) )
> return 1;
> else
> return 0;
>
> free(M1_STAT);
> free(M2_STAT);
> }
>
> double Count_Edges(int *X, int n)
> {
> double temp;
> int i, j;
>
> temp = 0;
>
> for(i = 1; i < n; i++)
> {
> for(j = 0; j < i; j++)
> {
> temp += X[i * n + j];
> }
> }
>
> return temp;
> }
>
> double Cal_GWD(int *X, int n)
> {
>
> int *M3, *Degree, *D_Y;
> int i, j;
> double theta = 0.25;
> double GWD = 0.00;
>
> M3 = (int *)calloc(n, sizeof(int));
> Degree = (int *)calloc(n, sizeof(int));
> D_Y = (int *)calloc((n - 1), sizeof(int));
>
> for(i = 0; i < n; i++)
> {
> for(j = 0; j < n; j++)
> {
> M3[j] = X[i * n + j];
> }
>
> Degree[i] = Cal_Degree(M3, n);
> }
>
> for(i = 0; i < n - 1; i++)
> {
> D_Y[i] = 0;
>
> for(j = 0; j < n; j++)
> {
> if(Degree[j] = i
[Rd] Hello! I got error in C - R
Hello,
My name is Ick Hoon Jin and I am Ph. D. student in Texas A & M Univ..
When I run the C embedded in R in the Linux system, I confront the
following error after 6,000 iteration. By googling I found this error is
from the problem in C.
*** caught segfault ***
address (nil), cause 'memory not mapped'
My C code is following:
---
#include
#include
#include
#include
#include
#define Min(X,Y) ((X) < (Y) ? (X) : (Y))
void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
*n_para, double *out);
int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n);
double Count_Edges(int *X, int n);
double Cal_GWD(int *X, int n);
int Cal_Degree(int *M3, int n);
double Inner_Product( double *vector1, double *vector2, int length);
int rdtsc();
void SecondMH(int *n, int *X, int *length_X, double *theta_new, int
*n_para, double *out)
{
int i, j, a, k;
int *M1, *M2;
M1 = (int *)calloc(*length_X, sizeof(int));
M2 = (int *)calloc(*length_X, sizeof(int));
for(i = 1; i < *n; i++)
{
for(j = 0; j < i; j++)
{
for(k = 0; k < *length_X; k++ )
{
M1[k] = X[k];
M2[k] = X[k];
}
if(X[i * *n + j] == 1)
{
M1[i * *n + j] = 0;
a = MH_Result(theta_new, *n_para, M1, M2, *n);
if(a == 1)
{
X[i * *n + j] = 0;
}
}
else
{
M1[i * *n + j] = 1;
a = MH_Result(theta_new, *n_para, M1, M2, *n);
if(a == 1)
{
X[i * *n + j] = 1;
}
}
}
}
for(i = 1; i < *n; i++)
{
for(j = 0; j < i; j++)
{
X[j * *n + i] = 0;
}
}
for(i = 0; i < *length_X; i++)
{
out[i] = (double)X[i];
}
free(M1);
free(M2);
return;
}
int MH_Result(double *theta_new, int n_para, int *M1, int *M2, int n)
{
double *M1_STAT, *M2_STAT;
double pi_Num, pi_Denom, MH_Ratio, v;
M1_STAT = (double *)calloc( n_para, sizeof( double ) );
M2_STAT = (double *)calloc( n_para, sizeof( double ) );
M1_STAT[0] = Count_Edges(M1, n);
M2_STAT[0] = Count_Edges(M2, n);
M1_STAT[1] = Cal_GWD(M1, n);
M2_STAT[1] = Cal_GWD(M2, n);
pi_Num = Inner_Product(theta_new, M1_STAT, n_para);
pi_Denom = Inner_Product(theta_new, M2_STAT, n_para);
MH_Ratio = pi_Num - pi_Denom;
srand(rdtsc());
v = (double)rand() / ( (double)RAND_MAX + (double)1 );
if( log( v ) < Min( 0, MH_Ratio ) )
return 1;
else
return 0;
free(M1_STAT);
free(M2_STAT);
}
double Count_Edges(int *X, int n)
{
double temp;
int i, j;
temp = 0;
for(i = 1; i < n; i++)
{
for(j = 0; j < i; j++)
{
temp += X[i * n + j];
}
}
return temp;
}
double Cal_GWD(int *X, int n)
{
int *M3, *Degree, *D_Y;
int i, j;
double theta = 0.25;
double GWD = 0.00;
M3 = (int *)calloc(n, sizeof(int));
Degree = (int *)calloc(n, sizeof(int));
D_Y = (int *)calloc((n - 1), sizeof(int));
for(i = 0; i < n; i++)
{
for(j = 0; j < n; j++)
{
M3[j] = X[i * n + j];
}
Degree[i] = Cal_Degree(M3, n);
}
for(i = 0; i < n - 1; i++)
{
D_Y[i] = 0;
for(j = 0; j < n; j++)
{
if(Degree[j] = i + 1)
{
D_Y[i] += 1;
}
}
}
for(i = 0; i < n-1; i++)
{
GWD += ( 1 - pow( (1 - exp(theta*(-1))), (i + 1) ) ) *
(double)D_Y[i];
}
GWD = GWD * exp(theta);
free(M3);
free(Degree);
free(D_Y);
return GWD;
}
int Cal_Degree(int *M3, int n)
{
int i, result;
result = 0;
for(i = 0; i < n; i++)
{
result += M3[i];
}
return result;
}
double Inner_Product(double *vector1, double *vector2, int length)
{
Re: [Rd] Compiler options for Makefile.win
Dear Gabor,
Thank you for your suggestion.
I forgot to mention that the build process ended with the following
dialog box:
Runtime Error!
Program: c:\Programme\R\R-2.9.0alpha\bin\Rterm.exe
R6034
An application has made an attempt to load the C runtime library
incorrectly.
Please contact the application's support team for more information.
Only after pressing OK there was no response of Rterm and I had to
terminate the build process manually. I am not sure if this means that
the build process got into an infinite loop.
Could you explain what you mean with running the vignette "by hand" line
by line?
How can I do this?
BTW, if the problem is within one of the vignettes, as you mention, I
assume that the problem may be at the following statements:
\begin{Sinput}
R> library(xps)
\end{Sinput}
<>=
library(xps)
@
I believe that the error occurs when trying to load "library(xps)".
Best regards
Christian
Gábor Csárdi wrote:
On Sun, Mar 29, 2009 at 9:31 PM, cstrato wrote:
[...]
- - - - - - - -
Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes
Compression decreased file by 442,726 bytes.
** building package indices ...
** MD5 sums
* DONE (xps)
* creating vignettes ...Terminating on signal SIGINT(2)
- - - - - - - -
As you see I had to terminate the build process manually after 15 min .
My question is now:
Do you know why I can build my package w/o problems when using option /MT
but not when using option /MD?
It seems that the building process got into an infinite loop while
creating the vignette. Some code in the vignette/package does not work
properly. Try running the vignette "by hand" line by line to see where
the problem is.
Gabor
As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded
today.
Thank you in advance.
Best regards
Christian
_._._._._._._._._._._._._._._._._._
C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
V.i.e.n.n.a A.u.s.t.r.i.a
e.m.a.i.l:cstrato at aon.at
_._._._._._._._._._._._._._._._._._
__
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
Re: [Rd] Compiler options for Makefile.win
Dear Uwe, My problem is that this is the only mailing list I know where to ask this question, since this problem is definitely related to R. When I compile my source code as stand alone library using NMAKE then both compiler options, /MD and /MT, work fine and I can use the compiled library from a C++ program w/o any problems. Only compiling the source code from within R results in the error when using /MD. BTW, I forgot to mention that when "R CMD build" stops at: * DONE (xps) * creating vignettes ... I get the following "Microsoft Visual C++ Runtime Library" dialogbox: Runtime Error! Program: c:\Programme\R\R-2.9.0alpha\bin\Rterm.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information. Best regards Christian Uwe Ligges wrote: I fear the number of R users under Windows that make use of a non-gcc compiler and is reading this list is quite close to 0. Hence you will probably have to find it out yourself. Uwe Ligges cstrato wrote: Dear all, For certain reasons I have to compile the source code of my package on Windows XP using Microsoft Visual Studio 9.0, thus I had to create a "Makefile.win". Now I have a question regarding compiler options /MT vs /MD for Makefile.win. The following partial output shows that when building my package on Windows XP using "R CMD build --binary xps" with compiler option /MT everything is ok: - - - - - - - - running src/Makefile.win ... "C:\Programme\Microsoft Visual Studio 9.0\VC\bin/cl" /I"C:\root/include" /FIw32p ragma.h /MT /EHsc /Ox /D "MSVC" /D "WIN32" /c TStat.cxx Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. TStat.cxx Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,304 bytes Compression decreased file by 442,728 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ... OK * cleaning src Created c:\home\Rabbitus\temp\Rbuild210430099\xps\chm\xps.chm, 166,308 bytes Compression decreased file by 442,724 bytes. ** building package indices ... ** MD5 sums packaged installation of 'xps' as xps_1.3.8.zip * DONE (xps) - - - - - - - - As you see the package was built correctly. However, when I change the compiler option in "Makefile.win" to /MD the build stops at the following position: - - - - - - - - Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes Compression decreased file by 442,726 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ...Terminating on signal SIGINT(2) - - - - - - - - As you see I had to terminate the build process manually after 15 min . My question is now: Do you know why I can build my package w/o problems when using option /MT but not when using option /MD? As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded today. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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
Re: [Rd] what is the preferred method to create a package local variable?
On 4/2/2009 9:41 AM, Whit Armstrong wrote:
Thanks to everyone for the suggestions.
The package local environment (per Roger Peng) works well.
.localstuff <- new.env()
.localstuff$bbg.db.conn <- dbConnect(...)
However, there is one thing that I'm confused about.
Why must the .localstuff variable be an environment?
If a package doesn't have a namespace, then its functions have their
environment set to the global environment, so they can stomp on user
things by accident. I'd say a better solution to this problem is that
every package should have a namespace, then there isn't the same risk of
messing with a user's variables.
I've tried the following, but the variable conn stays null during the
whole R session. Despite the database connection succeeding (I can
see the constructor printing to the console):
conn <- NULL
.onAttach <- function(libname, pkgname) {
conn <- dbConnect(dbDriver("PostgreSQL"), user="...")
}
That creates a new local variable called conn. Use
conn <<- dbConnect ...
to modify the package one. (Assuming you have a namespace; if not, that
will have different effects depending on whether or not the user has a
variable named conn. Yecch.)
Duncan Murdoch
.onUnload <- function(libpath) {
dbDisconnect(conn)
}
output from R session:
[warmstr...@linuxsvr R.packages]$ R
library(KLS)
Loading required package: fts
Loading required package: RCommodity
Loading required package: unifiedDBI
Loading required package: RFincad
Loading required package: RLIM
Loading required package: RBoostDateTime
PostgresConnection::PostgresConnection()
KLS:::conn
NULL
x <- get.bbg("EURUSD Curncy")
Error in get.bbg("EURUSD Curncy") : Database connection not initialized
q()
PostgresConnection::~PostgresConnection()
[warmstr...@linuxsvr R.packages]$
Thanks,
Whit
On Tue, Mar 31, 2009 at 3:51 PM, Philippe Grosjean
wrote:
The best way is to have those variable hidden in the package's workspace, as
explained by Roger Peng.
However, if you like to use a mechanism managing an environment specifically
dedicated to temporary variables very easily, look at assignTemp() and
getTemp() from svMisc package. The advantage is an easier sharing of such
variables between different packages (plus the bonus of easy management of
default values, overwriting or not of current content if the variable
already exists, ...). The temporary environment (TempEnv) is always located
in the forelast position just before 'base'.
In any cases, avoid using .GlobalEnv and the ugly <<- for that purpose.
Best,
Philippe Grosjean
Roger Peng wrote:
I usually use environments for this. So, in one of the R files for the
package, just do
.localstuff <- new.env()
Then, in functions you can do things like
.localstuff$bbg.db.conn <- dbConnect(...)
-roger
On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
wrote:
for the moment, I'm using:
.onAttach <- function(libname, pkgname) {
.bbg.db.conn <<- dbConnect(dbDriver("PostgreSQL"), user="blah","blah")
}
.onUnload <- function(libpath) {
dbDisconnect(.bbg.db.conn)
}
which results in a hidden global variable in the global environment.
I would prefer to make the assignment only in the package namespace.
I've looked at assignInNamespace, but I can't seem to make it work.
Is there a preferred method for doing this?
When I try adding an assignment directly in the source file, I get the
"cannot change value of locked binding" error.
What am I missing?
Thanks,
Whit
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what is the preferred method to create a package local variable?
On 4/2/2009 9:49 AM, Roger Peng wrote:
The use of an environment gets around the fact that package namespaces
are locked, so that values can't be changed once the package is
loaded. However, elements of environments can be changed.
Oops, I forgot about that. So use a NAMESPACE plus an environment.
Duncan Murdoch
-roger
On Thu, Apr 2, 2009 at 9:41 AM, Whit Armstrong wrote:
Thanks to everyone for the suggestions.
The package local environment (per Roger Peng) works well.
.localstuff <- new.env()
.localstuff$bbg.db.conn <- dbConnect(...)
However, there is one thing that I'm confused about.
Why must the .localstuff variable be an environment?
I've tried the following, but the variable conn stays null during the
whole R session. Despite the database connection succeeding (I can
see the constructor printing to the console):
conn <- NULL
.onAttach <- function(libname, pkgname) {
conn <- dbConnect(dbDriver("PostgreSQL"), user="...")
}
.onUnload <- function(libpath) {
dbDisconnect(conn)
}
output from R session:
[warmstr...@linuxsvr R.packages]$ R
library(KLS)
Loading required package: fts
Loading required package: RCommodity
Loading required package: unifiedDBI
Loading required package: RFincad
Loading required package: RLIM
Loading required package: RBoostDateTime
PostgresConnection::PostgresConnection()
KLS:::conn
NULL
x <- get.bbg("EURUSD Curncy")
Error in get.bbg("EURUSD Curncy") : Database connection not initialized
q()
PostgresConnection::~PostgresConnection()
[warmstr...@linuxsvr R.packages]$
Thanks,
Whit
On Tue, Mar 31, 2009 at 3:51 PM, Philippe Grosjean
wrote:
The best way is to have those variable hidden in the package's workspace, as
explained by Roger Peng.
However, if you like to use a mechanism managing an environment specifically
dedicated to temporary variables very easily, look at assignTemp() and
getTemp() from svMisc package. The advantage is an easier sharing of such
variables between different packages (plus the bonus of easy management of
default values, overwriting or not of current content if the variable
already exists, ...). The temporary environment (TempEnv) is always located
in the forelast position just before 'base'.
In any cases, avoid using .GlobalEnv and the ugly <<- for that purpose.
Best,
Philippe Grosjean
Roger Peng wrote:
I usually use environments for this. So, in one of the R files for the
package, just do
.localstuff <- new.env()
Then, in functions you can do things like
.localstuff$bbg.db.conn <- dbConnect(...)
-roger
On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
wrote:
for the moment, I'm using:
.onAttach <- function(libname, pkgname) {
.bbg.db.conn <<- dbConnect(dbDriver("PostgreSQL"), user="blah","blah")
}
.onUnload <- function(libpath) {
dbDisconnect(.bbg.db.conn)
}
which results in a hidden global variable in the global environment.
I would prefer to make the assignment only in the package namespace.
I've looked at assignInNamespace, but I can't seem to make it work.
Is there a preferred method for doing this?
When I try adding an assignment directly in the source file, I get the
"cannot change value of locked binding" error.
What am I missing?
Thanks,
Whit
__
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
Re: [Rd] what is the preferred method to create a package local variable?
aha!
Now it makes sense.
Thanks, Roger.
-Whit
On Thu, Apr 2, 2009 at 9:49 AM, Roger Peng wrote:
> The use of an environment gets around the fact that package namespaces
> are locked, so that values can't be changed once the package is
> loaded. However, elements of environments can be changed.
>
> -roger
>
> On Thu, Apr 2, 2009 at 9:41 AM, Whit Armstrong
> wrote:
>> Thanks to everyone for the suggestions.
>>
>> The package local environment (per Roger Peng) works well.
>> .localstuff <- new.env()
>> .localstuff$bbg.db.conn <- dbConnect(...)
>>
>> However, there is one thing that I'm confused about.
>>
>> Why must the .localstuff variable be an environment?
>>
>> I've tried the following, but the variable conn stays null during the
>> whole R session. Despite the database connection succeeding (I can
>> see the constructor printing to the console):
>>
>> conn <- NULL
>>
>> .onAttach <- function(libname, pkgname) {
>> conn <- dbConnect(dbDriver("PostgreSQL"), user="...")
>> }
>>
>> .onUnload <- function(libpath) {
>> dbDisconnect(conn)
>> }
>>
>> output from R session:
>>
>> [warmstr...@linuxsvr R.packages]$ R
>>> library(KLS)
>> Loading required package: fts
>> Loading required package: RCommodity
>> Loading required package: unifiedDBI
>> Loading required package: RFincad
>> Loading required package: RLIM
>> Loading required package: RBoostDateTime
>> PostgresConnection::PostgresConnection()
>>> KLS:::conn
>> NULL
>>> x <- get.bbg("EURUSD Curncy")
>> Error in get.bbg("EURUSD Curncy") : Database connection not initialized
>>> q()
>> PostgresConnection::~PostgresConnection()
>> [warmstr...@linuxsvr R.packages]$
>>
>>
>> Thanks,
>> Whit
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 31, 2009 at 3:51 PM, Philippe Grosjean
>> wrote:
>>> The best way is to have those variable hidden in the package's workspace, as
>>> explained by Roger Peng.
>>>
>>> However, if you like to use a mechanism managing an environment specifically
>>> dedicated to temporary variables very easily, look at assignTemp() and
>>> getTemp() from svMisc package. The advantage is an easier sharing of such
>>> variables between different packages (plus the bonus of easy management of
>>> default values, overwriting or not of current content if the variable
>>> already exists, ...). The temporary environment (TempEnv) is always located
>>> in the forelast position just before 'base'.
>>>
>>> In any cases, avoid using .GlobalEnv and the ugly <<- for that purpose.
>>> Best,
>>>
>>> Philippe Grosjean
>>>
>>>
>>> Roger Peng wrote:
I usually use environments for this. So, in one of the R files for the
package, just do
.localstuff <- new.env()
Then, in functions you can do things like
.localstuff$bbg.db.conn <- dbConnect(...)
-roger
On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
wrote:
>
> for the moment, I'm using:
>
> .onAttach <- function(libname, pkgname) {
> .bbg.db.conn <<- dbConnect(dbDriver("PostgreSQL"), user="blah","blah")
> }
>
> .onUnload <- function(libpath) {
> dbDisconnect(.bbg.db.conn)
> }
>
>
> which results in a hidden global variable in the global environment.
>
> I would prefer to make the assignment only in the package namespace.
> I've looked at assignInNamespace, but I can't seem to make it work.
>
> Is there a preferred method for doing this?
>
> When I try adding an assignment directly in the source file, I get the
> "cannot change value of locked binding" error.
>
> What am I missing?
>
> Thanks,
> Whit
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>>>
>>
>
>
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what is the preferred method to create a package local variable?
The use of an environment gets around the fact that package namespaces
are locked, so that values can't be changed once the package is
loaded. However, elements of environments can be changed.
-roger
On Thu, Apr 2, 2009 at 9:41 AM, Whit Armstrong wrote:
> Thanks to everyone for the suggestions.
>
> The package local environment (per Roger Peng) works well.
> .localstuff <- new.env()
> .localstuff$bbg.db.conn <- dbConnect(...)
>
> However, there is one thing that I'm confused about.
>
> Why must the .localstuff variable be an environment?
>
> I've tried the following, but the variable conn stays null during the
> whole R session. Despite the database connection succeeding (I can
> see the constructor printing to the console):
>
> conn <- NULL
>
> .onAttach <- function(libname, pkgname) {
> conn <- dbConnect(dbDriver("PostgreSQL"), user="...")
> }
>
> .onUnload <- function(libpath) {
> dbDisconnect(conn)
> }
>
> output from R session:
>
> [warmstr...@linuxsvr R.packages]$ R
>> library(KLS)
> Loading required package: fts
> Loading required package: RCommodity
> Loading required package: unifiedDBI
> Loading required package: RFincad
> Loading required package: RLIM
> Loading required package: RBoostDateTime
> PostgresConnection::PostgresConnection()
>> KLS:::conn
> NULL
>> x <- get.bbg("EURUSD Curncy")
> Error in get.bbg("EURUSD Curncy") : Database connection not initialized
>> q()
> PostgresConnection::~PostgresConnection()
> [warmstr...@linuxsvr R.packages]$
>
>
> Thanks,
> Whit
>
>
>
>
>
>
> On Tue, Mar 31, 2009 at 3:51 PM, Philippe Grosjean
> wrote:
>> The best way is to have those variable hidden in the package's workspace, as
>> explained by Roger Peng.
>>
>> However, if you like to use a mechanism managing an environment specifically
>> dedicated to temporary variables very easily, look at assignTemp() and
>> getTemp() from svMisc package. The advantage is an easier sharing of such
>> variables between different packages (plus the bonus of easy management of
>> default values, overwriting or not of current content if the variable
>> already exists, ...). The temporary environment (TempEnv) is always located
>> in the forelast position just before 'base'.
>>
>> In any cases, avoid using .GlobalEnv and the ugly <<- for that purpose.
>> Best,
>>
>> Philippe Grosjean
>>
>>
>> Roger Peng wrote:
>>>
>>> I usually use environments for this. So, in one of the R files for the
>>> package, just do
>>>
>>> .localstuff <- new.env()
>>>
>>> Then, in functions you can do things like
>>>
>>> .localstuff$bbg.db.conn <- dbConnect(...)
>>>
>>> -roger
>>>
>>> On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
>>> wrote:
for the moment, I'm using:
.onAttach <- function(libname, pkgname) {
.bbg.db.conn <<- dbConnect(dbDriver("PostgreSQL"), user="blah","blah")
}
.onUnload <- function(libpath) {
dbDisconnect(.bbg.db.conn)
}
which results in a hidden global variable in the global environment.
I would prefer to make the assignment only in the package namespace.
I've looked at assignInNamespace, but I can't seem to make it work.
Is there a preferred method for doing this?
When I try adding an assignment directly in the source file, I get the
"cannot change value of locked binding" error.
What am I missing?
Thanks,
Whit
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] what is the preferred method to create a package local variable?
Thanks to everyone for the suggestions.
The package local environment (per Roger Peng) works well.
.localstuff <- new.env()
.localstuff$bbg.db.conn <- dbConnect(...)
However, there is one thing that I'm confused about.
Why must the .localstuff variable be an environment?
I've tried the following, but the variable conn stays null during the
whole R session. Despite the database connection succeeding (I can
see the constructor printing to the console):
conn <- NULL
.onAttach <- function(libname, pkgname) {
conn <- dbConnect(dbDriver("PostgreSQL"), user="...")
}
.onUnload <- function(libpath) {
dbDisconnect(conn)
}
output from R session:
[warmstr...@linuxsvr R.packages]$ R
> library(KLS)
Loading required package: fts
Loading required package: RCommodity
Loading required package: unifiedDBI
Loading required package: RFincad
Loading required package: RLIM
Loading required package: RBoostDateTime
PostgresConnection::PostgresConnection()
> KLS:::conn
NULL
> x <- get.bbg("EURUSD Curncy")
Error in get.bbg("EURUSD Curncy") : Database connection not initialized
> q()
PostgresConnection::~PostgresConnection()
[warmstr...@linuxsvr R.packages]$
Thanks,
Whit
On Tue, Mar 31, 2009 at 3:51 PM, Philippe Grosjean
wrote:
> The best way is to have those variable hidden in the package's workspace, as
> explained by Roger Peng.
>
> However, if you like to use a mechanism managing an environment specifically
> dedicated to temporary variables very easily, look at assignTemp() and
> getTemp() from svMisc package. The advantage is an easier sharing of such
> variables between different packages (plus the bonus of easy management of
> default values, overwriting or not of current content if the variable
> already exists, ...). The temporary environment (TempEnv) is always located
> in the forelast position just before 'base'.
>
> In any cases, avoid using .GlobalEnv and the ugly <<- for that purpose.
> Best,
>
> Philippe Grosjean
>
>
> Roger Peng wrote:
>>
>> I usually use environments for this. So, in one of the R files for the
>> package, just do
>>
>> .localstuff <- new.env()
>>
>> Then, in functions you can do things like
>>
>> .localstuff$bbg.db.conn <- dbConnect(...)
>>
>> -roger
>>
>> On Tue, Mar 31, 2009 at 11:45 AM, Whit Armstrong
>> wrote:
>>>
>>> for the moment, I'm using:
>>>
>>> .onAttach <- function(libname, pkgname) {
>>> .bbg.db.conn <<- dbConnect(dbDriver("PostgreSQL"), user="blah","blah")
>>> }
>>>
>>> .onUnload <- function(libpath) {
>>> dbDisconnect(.bbg.db.conn)
>>> }
>>>
>>>
>>> which results in a hidden global variable in the global environment.
>>>
>>> I would prefer to make the assignment only in the package namespace.
>>> I've looked at assignInNamespace, but I can't seem to make it work.
>>>
>>> Is there a preferred method for doing this?
>>>
>>> When I try adding an assignment directly in the source file, I get the
>>> "cannot change value of locked binding" error.
>>>
>>> What am I missing?
>>>
>>> Thanks,
>>> Whit
>>>
>>> __
>>> 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
Re: [Rd] actual argument matching does not conform to the definition (PR#13636)
Thomas Lumley wrote: > > The explanation is that quote() is a primitive function and that the > argument matching rules do not apply to primitives. That section of > the R Language definition should say that primitives are excluded; it > is documented in ?.Primitive. thanks. indeed, the documentation -- the language *definition* -- should make this clear. so this is a bug in the definition, which does not match the implementation, which in turn is as intended (right?) ?.Primitive says: " The advantage of '.Primitive' over '.Internal' functions is the potential efficiency of argument passing. However, this is done by ignoring argument names and using positional matching of arguments (unless arranged differently for specific primitives such as 'rep'), so this is discouraged for functions of more than one argument. " what is discouraged? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] actual argument matching does not conform to the definition (PR#13634)
Thomas Lumley wrote: > > The explanation is that quote() is a primitive function and that the > argument matching rules do not apply to primitives. That section of > the R Language definition should say that primitives are excluded; it > is documented in ?.Primitive. thanks. indeed, the documentation -- the language *definition* -- should make this clear. so this is a bug in the definition, which does not match the implementation, which in turn is as intended (right?) ?.Primitive says: " The advantage of '.Primitive' over '.Internal' functions is the potential efficiency of argument passing. However, this is done by ignoring argument names and using positional matching of arguments (unless arranged differently for specific primitives such as 'rep'), so this is discouraged for functions of more than one argument. " what is discouraged? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] actual argument matching does not conform to the definition (PR#13635)
The explanation is that quote() is a primitive function and that the argument matching rules do not apply to primitives. That section of the R Language definition should say that primitives are excluded; it is documented in ?.Primitive. -thomas On Thu, 2 Apr 2009 w...@idi.ntnu.no wrote: > Full_Name: Wacek Kusnierczyk > Version: 2.10.0 r48269 > OS: Ubuntu 8.04 Linux 32 bit > Submission from: (NULL) (129.241.199.164) > > > In the following example (and many other cases): > > quote(a=1) > # 1 > > the argument matching is apparently incorrect wrt. the documentation (The R > Language Definition, v 2.8.1, sec. 4.3.2, p. 23), which specifies the > following > algorithm for argument matching: > > 1. Attempt to match named actual arguments to formal arguments exactly. > 2. For the arguments remaining from step 1, attempt to match named actual > arguments to formal arguments partially. > 3. For the arguments remaining from step 1, collectively match all unnamed > actual arguments to the formal argument '...', if available. > 4. If any arguments remain, declare an error. > > quote(a=1) qualifies for step 4: > > 1. The actual argument 'a' does not match exactly quote's only formal > argument, > 'expr'. > 2. The actual argument 'a' does not match partially quote's only formal > argument, 'expr'. > 3. quote has no formal argument '...', hence 'a' remains unmatched. > 4. An error should be raised. > > Instead, the actual argument 'a' is matched to the formal argument 'expr'. > This > clearly conflicts with the definition. Either the definition or the > implementation (or both) are wrong. > > The problem is not constrained to quote, and seems to be ubiquitous (though > does > not apply to all functions). > > There are additional minor issues with the documentation which were raised in > a > separate thread. > > Regards, > vQ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] actual argument matching does not conform to the definition (PR#13634)
The explanation is that quote() is a primitive function and that the argument matching rules do not apply to primitives. That section of the R Language definition should say that primitives are excluded; it is documented in ?.Primitive. -thomas On Thu, 2 Apr 2009 w...@idi.ntnu.no wrote: Full_Name: Wacek Kusnierczyk Version: 2.10.0 r48269 OS: Ubuntu 8.04 Linux 32 bit Submission from: (NULL) (129.241.199.164) In the following example (and many other cases): quote(a=1) # 1 the argument matching is apparently incorrect wrt. the documentation (The R Language Definition, v 2.8.1, sec. 4.3.2, p. 23), which specifies the following algorithm for argument matching: 1. Attempt to match named actual arguments to formal arguments exactly. 2. For the arguments remaining from step 1, attempt to match named actual arguments to formal arguments partially. 3. For the arguments remaining from step 1, collectively match all unnamed actual arguments to the formal argument '...', if available. 4. If any arguments remain, declare an error. quote(a=1) qualifies for step 4: 1. The actual argument 'a' does not match exactly quote's only formal argument, 'expr'. 2. The actual argument 'a' does not match partially quote's only formal argument, 'expr'. 3. quote has no formal argument '...', hence 'a' remains unmatched. 4. An error should be raised. Instead, the actual argument 'a' is matched to the formal argument 'expr'. This clearly conflicts with the definition. Either the definition or the implementation (or both) are wrong. The problem is not constrained to quote, and seems to be ubiquitous (though does not apply to all functions). There are additional minor issues with the documentation which were raised in a separate thread. Regards, vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiler options for Makefile.win
On Sun, Mar 29, 2009 at 9:31 PM, cstrato wrote: [...] > - - - - - - - - > Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes > Compression decreased file by 442,726 bytes. > ** building package indices ... > ** MD5 sums > * DONE (xps) > * creating vignettes ...Terminating on signal SIGINT(2) > - - - - - - - - > > As you see I had to terminate the build process manually after 15 min . > > My question is now: > Do you know why I can build my package w/o problems when using option /MT > but not when using option /MD? It seems that the building process got into an infinite loop while creating the vignette. Some code in the vignette/package does not work properly. Try running the vignette "by hand" line by line to see where the problem is. Gabor > As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded > today. > > Thank you in advance. > > Best regards > Christian > _._._._._._._._._._._._._._._._._._ > C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a > V.i.e.n.n.a A.u.s.t.r.i.a > e.m.a.i.l: cstrato at aon.at > _._._._._._._._._._._._._._._._._._ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabor Csardi UNIL DGM __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiler options for Makefile.win
I fear the number of R users under Windows that make use of a non-gcc compiler and is reading this list is quite close to 0. Hence you will probably have to find it out yourself. Uwe Ligges cstrato wrote: Dear all, For certain reasons I have to compile the source code of my package on Windows XP using Microsoft Visual Studio 9.0, thus I had to create a "Makefile.win". Now I have a question regarding compiler options /MT vs /MD for Makefile.win. The following partial output shows that when building my package on Windows XP using "R CMD build --binary xps" with compiler option /MT everything is ok: - - - - - - - - running src/Makefile.win ... "C:\Programme\Microsoft Visual Studio 9.0\VC\bin/cl" /I"C:\root/include" /FIw32p ragma.h /MT /EHsc /Ox /D "MSVC" /D "WIN32" /c TStat.cxx Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. TStat.cxx Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,304 bytes Compression decreased file by 442,728 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ... OK * cleaning src Created c:\home\Rabbitus\temp\Rbuild210430099\xps\chm\xps.chm, 166,308 bytes Compression decreased file by 442,724 bytes. ** building package indices ... ** MD5 sums packaged installation of 'xps' as xps_1.3.8.zip * DONE (xps) - - - - - - - - As you see the package was built correctly. However, when I change the compiler option in "Makefile.win" to /MD the build stops at the following position: - - - - - - - - Created c:\home\Rabbitus\CRAN\xps\chm\xps.chm, 166,306 bytes Compression decreased file by 442,726 bytes. ** building package indices ... ** MD5 sums * DONE (xps) * creating vignettes ...Terminating on signal SIGINT(2) - - - - - - - - As you see I had to terminate the build process manually after 15 min . My question is now: Do you know why I can build my package w/o problems when using option /MT but not when using option /MD? As a note, I am using "R-2.9.0alpha-win32.exe" which I have downloaded today. Thank you in advance. Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ __ 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
Re: [Rd] Assignment to string
Stavros Macrakis wrote:
> On Wed, Apr 1, 2009 at 5:11 PM, Wacek Kusnierczyk <
> waclaw.marcin.kusnierc...@idi.ntnu.no> wrote:
>
>
>> Stavros Macrakis wrote:
>> ...
>> i think this concords with the documentation in the sense that in an
>> assignment a string can work as a name. note that
>>
>>`foo bar` = 1
>>is.name(`foo`)
>># FALSE
>>
>> the issue is different here in that in is.name("foo") "foo" evaluates to
>> a string (it works as a string literal), while in is.name(`foo`) `foo`
>> evaluates to the value of the variable named 'foo' (with the quotes
>> *not* belonging to the name).
>>
>>
>
> Wacek, surely you are joking here. The object written `foo` (a name)
> *evaluates to* its value.
yes, which is the value of a variable named 'foo' (quotes not included
in the name), or with other words, the value of the variable foo.
> The object written "foo" (a string) evaluates to
> itself. This has nothing to do with the case at hand, since the left-hand
> side of an assignment statement is not evaluated in the normal way.
>
yes. i did support your point that the documentation is confusing wrt.
"foo" = 1
because "foo" is not a name (and in particular, not a quoted name).
>
>
>> ...with only a quick look at the sources (src/main/envir.c:1511), i guess
>> the first element to an assignment operator (i mean the left-assignment
>> operators) is converted to a name
>>
>
>
> Yes, clearly when the LHS of an assignment is a string it is being coerced
> to a name. I was simply pointing out that that is not consistent with the
> documentation, which requires a name on the LHS.
>
... but there is probably something going on in do_set (in
src/main/eval.c) before do_assign is called.
> - maclisp was designed by computer scientists in a research project,
>
>> - r is being implemented by statisticians for practical purposes.
>>
>>
>
> Well, I think it is overstating things to say that Maclisp was designed at
> all. Maclisp grew out of PDP-6 Lisp, with new features being added
> regularly. Maclisp itself wasn't a research project --
didn't say that; it was, as far as i know (and that's little) developed
as part, or in support of, the MIT research project MAC.
> there are vanishingly
> few papers about it in the academic literature, unlike contemporary research
> languages like Planner, EL/1, CLU, etc. In fact, there are many parallels
> with R -- it was in some sense a service project supporting AI and symbolic
> algebra research, with ad hoc features (a.k.a. hacks)
that's a parallel to r, i guess?
> being added regularly
> to support some new idea in AI or algebra. To circle back to the current
> discussion, Maclisp didn't even have strings as a data type until the
> mid-70's -- before that, atoms ('symbols' in more modern terminology) were
> the only way to represent strings. (And that lived on in Maxima for many
> decades...) See http://www.softwarepreservation.org/projects/LISP/ for
> documentation on the history of many different Lisps.
>
interesting, thanks.
> We learned many lessons with Maclisp. Well, actually two different sets of
> lessons were learned by two different communities. The Scheme community
> learned the importance of minimalist, clean, principled design.
and scheme is claimed to be the inspiration for r...
> The Common
> Lisp community learned the importance of large, well-designed libraries.
> Both learned the importance of standardization and clear specification.
> There is much to learn.
>
yes...
best,
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] actual argument matching does not conform to the definition (PR#13634)
Full_Name: Wacek Kusnierczyk Version: 2.10.0 r48269 OS: Ubuntu 8.04 Linux 32 bit Submission from: (NULL) (129.241.199.164) In the following example (and many other cases): quote(a=1) # 1 the argument matching is apparently incorrect wrt. the documentation (The R Language Definition, v 2.8.1, sec. 4.3.2, p. 23), which specifies the following algorithm for argument matching: 1. Attempt to match named actual arguments to formal arguments exactly. 2. For the arguments remaining from step 1, attempt to match named actual arguments to formal arguments partially. 3. For the arguments remaining from step 1, collectively match all unnamed actual arguments to the formal argument '...', if available. 4. If any arguments remain, declare an error. quote(a=1) qualifies for step 4: 1. The actual argument 'a' does not match exactly quote's only formal argument, 'expr'. 2. The actual argument 'a' does not match partially quote's only formal argument, 'expr'. 3. quote has no formal argument '...', hence 'a' remains unmatched. 4. An error should be raised. Instead, the actual argument 'a' is matched to the formal argument 'expr'. This clearly conflicts with the definition. Either the definition or the implementation (or both) are wrong. The problem is not constrained to quote, and seems to be ubiquitous (though does not apply to all functions). There are additional minor issues with the documentation which were raised in a separate thread. Regards, vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Definition of = vs. <-
Wacek Kusnierczyk wrote:
>
> and btw. the following is also weird:
>
> quote(a=1)
> # 1
>
> not because '=' works as named argument specifier (so that the result
> would be something like `=`(a, 1)),
i meant to write: not because '=' does not work as an assignment
operator (or otherwise the result would be ...)
> but because quote has no parameter
> named 'a', and i would expect an error to be raised:
>
> # hypothetical
> quote(a=1)
> # error: unused argument(s): (a = 1)
>
> as in, say
>
> vector(mode='list', i=1)
> # error: unused argument(s): (i = 1)
>
> it appears that, in fact, quite many r functions will gladly match a
> *named* argument with a *differently named* parameter. it is weird to
> the degree that it is *wrong* wrt. the 'r language definition', sec.
> 4.3.2 'argument matching', which says:
>
> "The first thing that occurs in a function evaluation is the matching of
> formal to the actual or
> supplied arguments. This is done by a three-pass process:
> 1. Exact matching on tags. For each named supplied argument the list of
> formal arguments is
> searched for an item whose name matches exactly. It is an error to
> have the same formal
> argument match several actuals or vice versa.
> 2. Partial matching on tags. Each remaining named supplied argument is
> compared to the
> remaining formal arguments using partial matching. If the name of
> the supplied argument
> matches exactly with the first part of a formal argument then the
> two arguments are con-
> sidered to be matched. It is an error to have multiple partial
> matches. Notice that if f
> <- function(fumble, fooey) fbody, then f(f = 1, fo = 2) is illegal,
> even though the 2nd
> actual argument only matches fooey. f(f = 1, fooey = 2) is legal
> though since the second
> argument matches exactly and is removed from consideration for
> partial matching. If the
> formal arguments contain ‘...’ then partial matching is only
> applied to arguments that
> precede it.
> 3. Positional matching. Any unmatched formal arguments are bound to
> unnamed supplied
> arguments, in order. If there is a ‘...’ argument, it will take up
> the remaining arguments,
> tagged or not.
>If any arguments remain unmatched an error is declared.
> "
>
> if you now consider the example of quote(a=1), with quote having *one*
> formal argument (parameter) named 'expr' (see ?quote), we see that:
>
> 1. there is no exact match between the formal 'expr' and the actual 'a'
>
> 2. there is no partial match between the formal 'expr' and the actual 'a'
>
> 3a. there is an unmatched formal argument ('expr'), but no unnamed
> actual argument. hence, 'expr' remains unmatched.
> 3b. there is no argument '...' (i think the r language definition is
> lousy and should say 'formal argument' here, as you can have it as an
> actual, too, as in quote('...'=1)). hence, the actual argument named
> 'a' will not be 'taken up'.
>
> there remain unmatched arguments (i guess the r language definition is
> lousy and should say 'unmatched actual arguments', as you can obviously
> have unmatched formals, as in eval(1)), hence an error should be
> 'declared' (i guess 'raised' is more appropriate).
>
> this does not happen in quote(a=1) (and many, many other cases), and
> this makes me infer that there is a *bug* in the implementation of
> argument matching, since it clearly does not conform to the definiton.
> hence, i cc: to r-devel, and will also report a bug in the usual way.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Definition of = vs. <-
Peter Dalgaard wrote:
> Wacek Kusnierczyk wrote:
>> Stavros Macrakis wrote:
`->`
>>> Error: object "->" not found
>>>
>>
>> that's weird!
>
> Why???
>
partly because it was april fools.
but more seriously, it's because one could assume that in any syntactic
expression with an operator involved, the operator maps to a semantic
object. it has been claimed on this list (as far as i recall; don't
ask me for reference, but if pressed, i'll find it) that any expression
of the form
is a syntactic variant for
``(, )
(which would, following that argumentation, make r a lisp-like language)
but this apparently does not apply to '->'. i would (naively, perhaps)
expect that `->` is a function, which, internally, may well just invert
the order of arguments and imemdiately call `<-`. the fact that
expressions involving '->' are converted, at the parse time, into ones
using '<-' is far from obvious to me (it is now, but not a priori):
quote(1->a)
# a <- 1
# why not: 1 -> a
# why not: `->`(1, a)
and btw. the following is also weird:
quote(a=1)
# 1
not because '=' works as named argument specifier (so that the result
would be something like `=`(a, 1)), but because quote has no parameter
named 'a', and i would expect an error to be raised:
# hypothetical
quote(a=1)
# error: unused argument(s): (a = 1)
as in, say
vector(mode='list', i=1)
# error: unused argument(s): (i = 1)
it appears that, in fact, quite many r functions will gladly match a
*named* argument with a *differently named* parameter. it is weird to
the degree that it is *wrong* wrt. the 'r language definition', sec.
4.3.2 'argument matching', which says:
"The first thing that occurs in a function evaluation is the matching of
formal to the actual or
supplied arguments. This is done by a three-pass process:
1. Exact matching on tags. For each named supplied argument the list of
formal arguments is
searched for an item whose name matches exactly. It is an error to
have the same formal
argument match several actuals or vice versa.
2. Partial matching on tags. Each remaining named supplied argument is
compared to the
remaining formal arguments using partial matching. If the name of
the supplied argument
matches exactly with the first part of a formal argument then the
two arguments are con-
sidered to be matched. It is an error to have multiple partial
matches. Notice that if f
<- function(fumble, fooey) fbody, then f(f = 1, fo = 2) is illegal,
even though the 2nd
actual argument only matches fooey. f(f = 1, fooey = 2) is legal
though since the second
argument matches exactly and is removed from consideration for
partial matching. If the
formal arguments contain ‘...’ then partial matching is only
applied to arguments that
precede it.
3. Positional matching. Any unmatched formal arguments are bound to
unnamed supplied
arguments, in order. If there is a ‘...’ argument, it will take up
the remaining arguments,
tagged or not.
If any arguments remain unmatched an error is declared.
"
if you now consider the example of quote(a=1), with quote having *one*
formal argument (parameter) named 'expr' (see ?quote), we see that:
1. there is no exact match between the formal 'expr' and the actual 'a'
2. there is no partial match between the formal 'expr' and the actual 'a'
3a. there is an unmatched formal argument ('expr'), but no unnamed
actual argument. hence, 'expr' remains unmatched.
3b. there is no argument '...' (i think the r language definition is
lousy and should say 'formal argument' here, as you can have it as an
actual, too, as in quote('...'=1)). hence, the actual argument named
'a' will not be 'taken up'.
there remain unmatched arguments (i guess the r language definition is
lousy and should say 'unmatched actual arguments', as you can obviously
have unmatched formals, as in eval(1)), hence an error should be
'declared' (i guess 'raised' is more appropriate).
this does not happen in quote(a=1) (and many, many other cases), and
this makes me infer that there is a *bug* in the implementation of
argument matching, since it clearly does not conform to the definiton.
hence, i cc: to r-devel, and will also report a bug in the usual way.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
