[Rd] what does negative indexing in a matrix mean?

[Itziar Frades Alzueta]

Hi,

Does anyone know what the negative indexing of a matrix mean?

 

I am using the RWeka and this evaluate classifier does not work on new
data like this

 

e <- evaluate_Weka_classifier(m1235,newdata=XW4, complexity =
FALSE,class = FALSE) 

 

while it work with negative indexing:

 

e <- evaluate_Weka_classifier(m1235,newdata=XW4[,-2], complexity =
FALSE,class = FALSE)

 

Although I do not understand what negative indexing of a matrix means,
or whether it produces any transformation.

 

Regards,

 

Itziar Frades

 


 
 
 
This e-mail is from CIC bioGUNE. The e-mail and any files transmitted with it 
are confidential and intended solely for the use of the individual or entity to 
whom they are addressed. Any unauthorised dissemination or copying of this 
e-mail or its attachments, and any use or disclosure of any information 
contained in them, is strictly prohibited and may be illegal. If you have 
received this e-mail in error, please notify or telephone + 34 944 06 13 00 and 
delete it from your system.



[[alternative HTML version deleted]]

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

Re: [Rd] what does negative indexing in a matrix mean?

[Simon Urbanek]

On Nov 12, 2008, at 11:28 , Itziar Frades Alzueta wrote:


Hi,

Does anyone know what the negative indexing of a matrix mean?




?`[`

 For '['-indexing only: 'i, j, ...' can be logical vectors,
  indicating elements/slices to select.  Such vectors are
  recycled if necessary to match the corresponding extent.  'i,
  j, ...' can also be negative integers, indicating
  elements/slices to leave out of the selection.

.. so in your case you're removing one of the predictors (and I don't  
think you really have a matrix there ...).


Cheers,
S





I am using the RWeka and this evaluate classifier does not work on new
data like this



e <- evaluate_Weka_classifier(m1235,newdata=XW4, complexity =
FALSE,class = FALSE)



while it work with negative indexing:



e <- evaluate_Weka_classifier(m1235,newdata=XW4[,-2], complexity =
FALSE,class = FALSE)



Although I do not understand what negative indexing of a matrix means,
or whether it produces any transformation.



Regards,



Itziar Frades







This e-mail is from CIC bioGUNE. The e-mail and any files  
transmitted with it are confidential and intended solely for the use  
of the individual or entity to whom they are addressed. Any  
unauthorised dissemination or copying of this e-mail or its  
attachments, and any use or disclosure of any information contained  
in them, is strictly prohibited and may be illegal. If you have  
received this e-mail in error, please notify or telephone + 34 944  
06 13 00 and delete it from your system.




[[alternative HTML version deleted]]

__
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

[Rd] Splus-specific entries in pkg/DESCRIPTION files

[William Dunlap]

In the past few years we have been working on making
it possible to use packages in both R and Spotfire S+
(previously officially called S-PLUS).  One problem was
that certain lines in the DESCRIPTION file of a package
needed to be specific to R or Spotfire S+.  E.g., if
your package used the xyplot() function then the package
would depend upon lattice in R and trellis in Spotfire S+,
or a package might require R 2.8.0 or S+ 8.1 to work properly.
Another example might be that R's build system requires
that the Maintainer: line contains an e-mail address but
in Spotfire S+ a URL is acceptable.  

Our solution to this is that if a DESCRIPTION file has
entries tagged 'Xyx:' and 'XyzSplus:' then S+'s read.dcf()
function will ignore the 'Xyz:' entry and output the 'XyzSplus:'
entry as the 'Xyz:' entry.  E.g., the Depends: example above
would be handled by putting the following 2 lines in DESCRIPTION
   Depends: R (>= 2.8.0), lattice
   DependsSplus: Splus (>= 8.1), trellis
When R's read.dcf() reads that DESCRIPTION file the Depends
component of its output would be "R (>= 2.8.0), lattice" and
when S+'s read.dcf() reads it the Depends component would 
be "Splus (>= 8.1), trellis".  R's read.dcf() would also return
the component "DependsSplus", but that should not hurt anything
as long as the Depends component were also present (otherwise
partial matching could cause x$Depends to give you x$DependsSplus).

The Maintainer: issue would be handled by
   Maintainer: Joe the Package Writer <[EMAIL PROTECTED]>
   MaintainerSplus: Acme Support 

S+'s read.dcf() has an argument, convertSplusLines=TRUE, that one
can use to avoid this translation (useful mainly when copying
DESCRIPTION
files by using write.dcf(read.dcf(oldfile),newfile)).

This should not affect how things work in R (unless a package writer
had a tag ending with 'Splus') but package writers may find it handy
or may wonder why we add such lines when we help port their packages to
Spotfire S+.

This feature is new to Spotfire S+ 8.1.

Bill Dunlap
TIBCO Spotfire Inc
wdunlap tibco.com 

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

[Rd] Package install problem on Windows (PR#13284)

[lhansen]

Full_Name: Lars Hansen
Version: 2.8.0
OS: Windows XP Pro x64 SP2
Submission from: (NULL) (71.39.177.36)


Hi,

I have run into a problem using "R CMD INSTALL" with the
"--with-package-versions" option under Windows. It is a bit obscure, which could
explain why other people have not run into it.

We happen to have two packages with almost the same name. One name is a subset
of the other. The names are "RtTests" and "RtTestsEG1".  I have no problem
installing "RtTests" and many other packages, but run into problems installing
"RtTestsEG1". The "RtTestsEG1" package happens to be a simple example of how to
use the "RtTests" package, so it depends on "RtTests" (which is probably the
problem).

OK, so this is what happens when I attempt to install "RtTestsEG1":

$ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1

  installing RtTestsEG1 package

-- Making package RtTestsEG1 
  adding build stamp to DESCRIPTION
  installing R files
  preparing package RtTestsEG1 for lazy loading
Loading required package: RtTests
... [lost of lines removed]
Loading required package: RtTests
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-RtTestsEG1] Error 2
*** Installation of RtTestsEG1 failed ***

After some digging in the Windows makefiles, I found out that changing the
locale from "C" to "us" in the "lazyload" target of
$R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of "LC_ALL=C",
solves the infinite recursion problem and give an useful message. It still fails
but now says:

Loading required package: RtTests
Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults',
'print.RtTestSetResults.summary' were declared in NAMESPACE but not found
Error in namespaceExport(ns, exports) :
  undefined exports: parseTranscriptFile, compareTranscriptAndOutput
Error: package 'RtTests' could not be loaded
Execution halted

It is true that RtTests declares the various functions in its name space, but
why can they suddenly not be found? If I load RtTests by itself, i.e.
library(RtTests), there is no problem.

I happen to have all this working under Linux, so I tracked down the difference.
Turns out that under Linux the equivalent to the "lazyload" target is in
"/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to
"tools:::makeLazyLoading". Under Linux the full package name with version number
is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests".

So I managed to fix the problem by making Windows use the full package name in
the "lazyload" target. I replaced
  tools:::makeLazyLoading(\"$(PKG)\"
with
  tools:::makeLazyLoading(\"$(notdir $(DPKG))\"

If I now reinstall "RtTests", I can finally install "RtTestsEG1".

I must confess, that I do not fully understand exactly what it takes to
reproduce this problem. I am guessing that all it takes is a package depending
on a versioned package. Maybe the similarity in names introduces a problem
because of partial matching. I am guessing that has nothing to do with it.

To sum up the report. I see two problems:

1) LC_ALL=C causes infinite recursion. It is as if the C locale does not work
under Windows. I do not know what the fix is. It is used many places in install
scripts and makefiles. Fixing it in the "lazyload" target is not enough. Even
with my change I still get "infinite recursion" and no error message if I try to
install "RtTestsEG1" without first installing "RtTests".

2) "makeLazyLoading()" in "lazyload" target needs to be called with full package
name with embedded version number. I think this is bug under Windows and my fix
takes care of it.

It took some time to figure this out. I am hoping this report will save other
people time. I am note sure if I succeeded in describing the problem clearly.
Please do not hesitate to ask for clarification.

Thanks,
Lars Hansen

P.S.
> sessionInfo()
R version 2.8.0 Patched (2008-10-22 r46776)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

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

Re: [Rd] Dynamic linking to binary code from other packages??

[Jeff Ryan]

Charles,

> I've looked through the "Writing R Extensions" manual, and can't find
> this documented very clearly.  A previous question to the list gave me
> the very kind response pasted below.  I've looked at the suggested
> examples (lme4 using C functions from Matrix).

It isn't really "clearly" explained.  I will give it a try though.

You can't use compiled/packaged functions from within _your_ compiled
code unless the package that you are referring to (affxparser) makes
them available for export.

If affxparser doesn't do this you are back to Dirk's method.

For the sake of others who have gone down this road I will explain
what I know, and probably in the process learn what I may be doing
wrong. (all of this I learned by reading the sources for R and lme4
and Matrix).

Matrix has a copy of the Matrix.h header in its /inst directory,
specifically /inst/include/Matrix.h

This gets installed as /include/Matrix.h, which is where LinkingTo
links to during compilation.

You (or the affxparser author) will also need a handful of C calls
that are complementary to ones in the package you are getting the
functions from.

An example from Matrix:

/include/Matrix_stubs.c contains

...
CHM_DN attribute_hidden
M_as_cholmod_dense(CHM_DN ans, SEXP x)
{
static CHM_DN(*fun)(CHM_DN,SEXP) = NULL;
if(fun == NULL)
fun = (CHM_DN(*)(CHM_DN,SEXP))
R_GetCCallable("Matrix", "as_cholmod_dense");
return fun(ans, x);
}
...

The above is far from obvious, so I will try my best to explain.

With respect to the R_GetCCallable call, Writing R Extensions says:

" p_myCfun = R_GetCCallable("packA", "myCfun");
The author of packB is responsible for ensuring that p_myCfun has an
appropriate declaration. What exactly that means was hard to determine
at first."

Taking the first line, the first CHM_DN is the function return type
(could be int, SEXP, etc), and the second (along with the SEXP) is the
argument type(s).

Generalized you'd have something like:

SEXP attribute_hidden
FUNNAME(SEXP ans, SEXP x)
{
static SEXP(*fun)(SEXP,SEXP) = NULL;
if(fun == NULL)
fun = (SEXP(*)(SEXP,SEXP))
R_GetCCallable("PACKAGE", "FUNCTION");
return fun(ans, x);
}

lme4 then simply "#include"s this .c file in a file
/src/local_stubs.c, which is compiled right along side of the src code
in lme4.

At this point you can then use the functions that are
'exported/registered' as you would a C function defined in your own
package.

The other side of this is what the Matrix (affxparser?) package needs
to do.  It needs a registration routine that specifically registers
the routines as callable using:
  R_RegisterCCallable  (which is documented in Writing R Extensions)

In Matrix this is in /src/init.c via a macro.

A simpler in-progress bit of code can be found in the /dev branch of
xts on R-forge.  Take a look at

http://r-forge.r-project.org/scm/?group_id=118

/dev/src/init.c
/dev/inst/include/xts.h
/dev/inst/include/xts_stubs.c

As far as C++ goes, I would suspect the Matrix package again has all
the bits you are looking for.

HTH
Jeff




-- 
Jeffrey Ryan
[EMAIL PROTECTED]

ia: insight algorithmics
www.insightalgo.com

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

Re: [Rd] Package install problem on Windows (PR#13284)

[Prof Brian Ripley]

Installing versioned packages is not supported with namespaces.  I have 
suggested from time to time that versioned installs be removed because of 
this and other known issues, and recommend that you do not attempt to use 
them.


On Thu, 13 Nov 2008, [EMAIL PROTECTED] wrote:


Full_Name: Lars Hansen
Version: 2.8.0
OS: Windows XP Pro x64 SP2
Submission from: (NULL) (71.39.177.36)


Hi,

I have run into a problem using "R CMD INSTALL" with the
"--with-package-versions" option under Windows. It is a bit obscure, which could
explain why other people have not run into it.

We happen to have two packages with almost the same name. One name is a subset
of the other. The names are "RtTests" and "RtTestsEG1".  I have no problem
installing "RtTests" and many other packages, but run into problems installing
"RtTestsEG1". The "RtTestsEG1" package happens to be a simple example of how to
use the "RtTests" package, so it depends on "RtTests" (which is probably the
problem).

OK, so this is what happens when I attempt to install "RtTestsEG1":

$ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1

 installing RtTestsEG1 package

-- Making package RtTestsEG1 
 adding build stamp to DESCRIPTION
 installing R files
 preparing package RtTestsEG1 for lazy loading
Loading required package: RtTests
... [lost of lines removed]
Loading required package: RtTests
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-RtTestsEG1] Error 2
*** Installation of RtTestsEG1 failed ***

After some digging in the Windows makefiles, I found out that changing the
locale from "C" to "us" in the "lazyload" target of
$R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of "LC_ALL=C",
solves the infinite recursion problem and give an useful message. It still fails
but now says:

Loading required package: RtTests
Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults',
'print.RtTestSetResults.summary' were declared in NAMESPACE but not found
Error in namespaceExport(ns, exports) :
 undefined exports: parseTranscriptFile, compareTranscriptAndOutput
Error: package 'RtTests' could not be loaded
Execution halted

It is true that RtTests declares the various functions in its name space, but
why can they suddenly not be found? If I load RtTests by itself, i.e.
library(RtTests), there is no problem.

I happen to have all this working under Linux, so I tracked down the difference.
Turns out that under Linux the equivalent to the "lazyload" target is in
"/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to
"tools:::makeLazyLoading". Under Linux the full package name with version number
is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests".

So I managed to fix the problem by making Windows use the full package name in
the "lazyload" target. I replaced
 tools:::makeLazyLoading(\"$(PKG)\"
with
 tools:::makeLazyLoading(\"$(notdir $(DPKG))\"

If I now reinstall "RtTests", I can finally install "RtTestsEG1".

I must confess, that I do not fully understand exactly what it takes to
reproduce this problem. I am guessing that all it takes is a package depending
on a versioned package. Maybe the similarity in names introduces a problem
because of partial matching. I am guessing that has nothing to do with it.

To sum up the report. I see two problems:

1) LC_ALL=C causes infinite recursion. It is as if the C locale does not work
under Windows. I do not know what the fix is. It is used many places in install
scripts and makefiles. Fixing it in the "lazyload" target is not enough. Even
with my change I still get "infinite recursion" and no error message if I try to
install "RtTestsEG1" without first installing "RtTests".

2) "makeLazyLoading()" in "lazyload" target needs to be called with full package
name with embedded version number. I think this is bug under Windows and my fix
takes care of it.

It took some time to figure this out. I am hoping this report will save other
people time. I am note sure if I succeeded in describing the problem clearly.
Please do not hesitate to ask for clarification.

Thanks,
Lars Hansen

P.S.

sessionInfo()

R version 2.8.0 Patched (2008-10-22 r46776)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

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



--
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: