[Rd] c(, expression instead of list

2009-08-27 Thread Martin Maechler
Dear programmeRs,

I'm proposing and looking into implementing a small change in
R's  c() handling of 'symbol's aka 'name's, and potentially also
'language' parts.

The main motivation is transparent programmatic construction of
expression()s;  and important use cases are expressions used for
"plot math", typically in 
axis(.., labels = *)   
orlegend(.., legend = *)

[BTW, Paul,  in  grid.legend(*, labels = *),  labels is *not*
 allowed to be an expression]

Look at this code snippet {where the comments include the
results you see} :

e <- expression(a, gamma, nu == 50, x^2 == 3.14, y <- 17, { x[i] <- sin(y^2 + 
exp(u[i])) })
length(e)
## 6
## Ok, what are the components like ?
##
sapply(e, is.language)
## [1] TRUE TRUE TRUE TRUE TRUE TRUE
## aha, all are  "language",
##
## and specifically :
sapply(e, typeof)
##[1] "symbol"   "symbol"   "language" "language"   "language" "language"
## or in ``S - compatible'' language  {but S+ slightly differs here}:
sapply(e, mode)
##[1] "name" "name" "call" "call" "call" "call"
sapply(e, class)
##[1] "name" "name" "call" "call" "<-"   "{"

Now, in "plotmath" situations,
you'd often want the '50' , '3.14' or '17'  be the content of
other R variables, and so we need  substitute()  or  bquote(),
and these directly result in "name" or "language" objects :

However, you cannot very easily concatenate them to an
expression:

z <- c(88, 143)
(e1 <- substitute(x[1]^2 == v, list(v = z[1])))
(e2 <- bquote(pi / r[i]^2 == .(z[2])))

## However,
c(e1, e2)  ## is a list, not an expression ...
## but 
plot(1, type="n")
legend("top",legend= c(e1,e2)) ## is ugly (no super/sub scripts ...)
legend("center", legend=
   c(as.expression(e1),
 as.expression(e2)))# works but is a bit cumbersome

-

So now, my proposition is to make the  "as.expression()"
implicit in  c(),
since the  help file for c() does mention that

>  The output type is determined from the highest type of the
>  components in the hierarchy NULL < raw < logical < integer < real
>  < complex < character < list < expression. .

and implicitly,  "symbol" and "language" are treated  by as.list()
rather than as expression-like.

I would like to change this, i.e.,  c() should  result in
"expression" rather than "list"  when it's applied to symbola
and language types.

Note that S-plus 8.0.4, and 3.4 does this very differently
anyway.

Martin Maechler, ETH Zurich

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


Re: [Rd] c(, expression instead of list

2009-08-27 Thread Gabor Grothendieck
On Thu, Aug 27, 2009 at 6:18 AM, Martin
Maechler wrote:
> Dear programmeRs,
>
> I'm proposing and looking into implementing a small change in
> R's  c() handling of 'symbol's aka 'name's, and potentially also
> 'language' parts.
>
> The main motivation is transparent programmatic construction of
> expression()s;  and important use cases are expressions used for
> "plot math", typically in
>        axis(.., labels = *)
> or    legend(.., legend = *)
>
> [BTW, Paul,  in  grid.legend(*, labels = *),  labels is *not*
>  allowed to be an expression]
>
> Look at this code snippet {where the comments include the
> results you see} :
>
> e <- expression(a, gamma, nu == 50, x^2 == 3.14, y <- 17, { x[i] <- sin(y^2 + 
> exp(u[i])) })
> length(e)
> ## 6
> ## Ok, what are the components like ?
> ##
> sapply(e, is.language)
> ## [1] TRUE TRUE TRUE TRUE TRUE TRUE
> ## aha, all are  "language",
> ##
> ## and specifically :
> sapply(e, typeof)
> ##[1] "symbol"   "symbol"   "language" "language"   "language" "language"
> ## or in ``S - compatible'' language  {but S+ slightly differs here}:
> sapply(e, mode)
> ##[1] "name" "name" "call" "call" "call" "call"
> sapply(e, class)
> ##[1] "name" "name" "call" "call" "<-"   "{"
>
> Now, in "plotmath" situations,
> you'd often want the '50' , '3.14' or '17'  be the content of
> other R variables, and so we need  substitute()  or  bquote(),
> and these directly result in "name" or "language" objects :
>
> However, you cannot very easily concatenate them to an
> expression:
>
> z <- c(88, 143)
> (e1 <- substitute(x[1]^2 == v, list(v = z[1])))
> (e2 <- bquote(pi / r[i]^2 == .(z[2])))
>
> ## However,
> c(e1, e2)  ## is a list, not an expression ...

although as.expression(c(e1, e2)) is an expression.

plot(0)
legend("top", as.expression(c(e1, e2)))

in light of which the savings is just one as.expression().

Another possibility would be to add support for
multiple arguments to bquote:

plot(0)
legend("top", bquote(x[1]^2 == .(z[1]), pi / r[i]^2 == .(z[2])))

Then we would not need to use c() in the first place.

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


Re: [Rd] c(, expression instead of list

2009-08-27 Thread Martin Maechler
> "GaGr" == Gabor Grothendieck 
> on Thu, 27 Aug 2009 07:32:42 -0400 writes:

GaGr> On Thu, Aug 27, 2009 at 6:18 AM, Martin
GaGr> Maechler wrote:
>> Dear programmeRs,
>> 
>> I'm proposing and looking into implementing a small change in
>> R's  c() handling of 'symbol's aka 'name's, and potentially also
>> 'language' parts.
>> 
>> The main motivation is transparent programmatic construction of
>> expression()s;  and important use cases are expressions used for
>> "plot math", typically in
>>        axis(.., labels = *)
>> or    legend(.., legend = *)
>> 
>> [BTW, Paul,  in  grid.legend(*, labels = *),  labels is *not*
>>  allowed to be an expression]
>> 
>> Look at this code snippet {where the comments include the
>> results you see} :
>> 
>> e <- expression(a, gamma, nu == 50, x^2 == 3.14, y <- 17, { x[i] <- 
sin(y^2 + exp(u[i])) })
>> length(e)
>> ## 6
>> ## Ok, what are the components like ?
>> ##
>> sapply(e, is.language)
>> ## [1] TRUE TRUE TRUE TRUE TRUE TRUE
>> ## aha, all are  "language",
>> ##
>> ## and specifically :
>> sapply(e, typeof)
>> ##[1] "symbol"   "symbol"   "language" "language"   "language" "language"
>> ## or in ``S - compatible'' language  {but S+ slightly differs here}:
>> sapply(e, mode)
>> ##[1] "name" "name" "call" "call" "call" "call"
>> sapply(e, class)
>> ##[1] "name" "name" "call" "call" "<-"   "{"
>> 
>> Now, in "plotmath" situations,
>> you'd often want the '50' , '3.14' or '17'  be the content of
>> other R variables, and so we need  substitute()  or  bquote(),
>> and these directly result in "name" or "language" objects :
>> 
>> However, you cannot very easily concatenate them to an
>> expression:
>> 
>> z <- c(88, 143)
>> (e1 <- substitute(x[1]^2 == v, list(v = z[1])))
>> (e2 <- bquote(pi / r[i]^2 == .(z[2])))
>> 
>> ## However,
>> c(e1, e2)  ## is a list, not an expression ...

GaGr> although as.expression(c(e1, e2)) is an expression.

GaGr> plot(0)
GaGr> legend("top", as.expression(c(e1, e2)))

GaGr> in light of which the savings is just one as.expression().

That's correct.
But my main point is that it's unnatural that
an expression is "list-like" with components "language"
and when I use  c() on these language-parts I don't get back the
expression.


GaGr> Another possibility would be to add support for
GaGr> multiple arguments to bquote:

GaGr> plot(0)
GaGr> legend("top", bquote(x[1]^2 == .(z[1]), pi / r[i]^2 == .(z[2])))

well, that would solve the use case I gave, 
but would actually result in making  bquote() return
*either* a 'language'/'symbol'  *or*  an 'expression';
which is called polymorphic behavior and often can be slightly
confusing/complicating.

GaGr> Then we would not need to use c() in the first place.

(in that use case, yes)

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


Re: [Rd] c(, expression instead of list

2009-08-27 Thread Gabor Grothendieck
On Thu, Aug 27, 2009 at 8:19 AM, Martin
Maechler wrote:
>> "GaGr" == Gabor Grothendieck 
>>     on Thu, 27 Aug 2009 07:32:42 -0400 writes:
>
>    GaGr> On Thu, Aug 27, 2009 at 6:18 AM, Martin
>    GaGr> Maechler wrote:
>    >> Dear programmeRs,
>    >>
>    >> I'm proposing and looking into implementing a small change in
>    >> R's  c() handling of 'symbol's aka 'name's, and potentially also
>    >> 'language' parts.
>    >>
>    >> The main motivation is transparent programmatic construction of
>    >> expression()s;  and important use cases are expressions used for
>    >> "plot math", typically in
>    >>        axis(.., labels = *)
>    >> or    legend(.., legend = *)
>    >>
>    >> [BTW, Paul,  in  grid.legend(*, labels = *),  labels is *not*
>    >>  allowed to be an expression]
>    >>
>    >> Look at this code snippet {where the comments include the
>    >> results you see} :
>    >>
>    >> e <- expression(a, gamma, nu == 50, x^2 == 3.14, y <- 17, { x[i] <- 
> sin(y^2 + exp(u[i])) })
>    >> length(e)
>    >> ## 6
>    >> ## Ok, what are the components like ?
>    >> ##
>    >> sapply(e, is.language)
>    >> ## [1] TRUE TRUE TRUE TRUE TRUE TRUE
>    >> ## aha, all are  "language",
>    >> ##
>    >> ## and specifically :
>    >> sapply(e, typeof)
>    >> ##[1] "symbol"   "symbol"   "language" "language"   "language" 
> "language"
>    >> ## or in ``S - compatible'' language  {but S+ slightly differs here}:
>    >> sapply(e, mode)
>    >> ##[1] "name" "name" "call" "call" "call" "call"
>    >> sapply(e, class)
>    >> ##[1] "name" "name" "call" "call" "<-"   "{"
>    >>
>    >> Now, in "plotmath" situations,
>    >> you'd often want the '50' , '3.14' or '17'  be the content of
>    >> other R variables, and so we need  substitute()  or  bquote(),
>    >> and these directly result in "name" or "language" objects :
>    >>
>    >> However, you cannot very easily concatenate them to an
>    >> expression:
>    >>
>    >> z <- c(88, 143)
>    >> (e1 <- substitute(x[1]^2 == v, list(v = z[1])))
>    >> (e2 <- bquote(pi / r[i]^2 == .(z[2])))
>    >>
>    >> ## However,
>    >> c(e1, e2)  ## is a list, not an expression ...
>
>    GaGr> although as.expression(c(e1, e2)) is an expression.
>
>    GaGr> plot(0)
>    GaGr> legend("top", as.expression(c(e1, e2)))
>
>    GaGr> in light of which the savings is just one as.expression().
>
> That's correct.
> But my main point is that it's unnatural that
> an expression is "list-like" with components "language"
> and when I use  c() on these language-parts I don't get back the
> expression.
>
>
>    GaGr> Another possibility would be to add support for
>    GaGr> multiple arguments to bquote:
>
>    GaGr> plot(0)
>    GaGr> legend("top", bquote(x[1]^2 == .(z[1]), pi / r[i]^2 == .(z[2])))
>
> well, that would solve the use case I gave,
> but would actually result in making  bquote() return
> *either* a 'language'/'symbol'  *or*  an 'expression';
> which is called polymorphic behavior and often can be slightly
> confusing/complicating.

But that is already how quote() works, i.e. it can return objects
of different classes so that would not be unexpected.

>
>    GaGr> Then we would not need to use c() in the first place.
>
> (in that use case, yes)
>

Another possibility is to create equote() which would be like a multi-argument
bquote but consistently produces an expression.   That would be more
convenient than writing c(bquote(...), bquote(...))

Note that nothing here prevents the c() enhancement to be done as well.
The two approaches are independent.

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


Re: [Rd] Clarifications please.

2009-08-27 Thread Abhijit Bera
Hi Martin

Sorry, I made a mistake, I wasn't looking at the syntactic correctness of
your code, I just followed what you suggested.

Your method is valid when I want to extract data from a class. I was trying
to get data from a covariance matrix. I'll put up code in my next mail
showing how to access the different data types using different methods.

Regards

Abhijit Bera


On Wed, Aug 26, 2009 at 10:25 PM, Martin Morgan  wrote:

> Hi Abhijit --
>
> Abhijit Bera wrote:
> > Hi Martin
> >
> > Thanks. I think I got it! Read the R extensions documentation again. I
> > don't even need to convert to a list. This is what I did (just a demo):
> >
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > int main (int argc, char** argv)  {
> >
> > SEXP e,t1,t2,val;
> > int errorOccurred,nx,ny,i,j;
> > double *v;
> >
> > Rf_initEmbeddedR(argc, argv);
> >
> > PROTECT(e = lang2(install("library"), mkString("fPortfolio")));
> > R_tryEval(e, R_GlobalEnv, NULL);
> > UNPROTECT(1);
> >
> > /* We try to evaluate the R expression:
> > *  round(cov(100 * SWX.RET), digits = 4)
> > *  we shall split it as:
> > *  t1<-100*SWX.RET
> > *  t2<-cov(t1)
> > *  val<-round(t2,4)
> > */
> >
> > PROTECT(e = lang3(install("*"),ScalarInteger(100),
> install("SWX.RET")));
> > PROTECT(t1 = (R_tryEval(e, NULL, &errorOccurred)));
>
> For what it's worth, and realizing that this is sloppiness in my
> original code, ScalarInteger(100) (and mkString("fPortfolio")) returns
> an unprotected SEXP, so it could in principle be garbage collected while
> lang3 is being evaluated...
>
> >
> > PROTECT(e = lang2(install("cov"),t1));
> > PROTECT(t2 = (R_tryEval(e, NULL, &errorOccurred)));
> >
> > PROTECT(e = lang3(install("round"),t2, ScalarInteger(4)));
> > PROTECT(val = (R_tryEval(e, NULL, &errorOccurred)));
> >
> > Rf_PrintValue(val);
> >
> >/* This isn't required, is extraneous.
> > PROTECT(e = lang2(install("as.list"),val));
> > PROTECT(t2 = (R_tryEval(e, NULL, &errorOccurred)));
> >
> > Rf_PrintValue(t2);*/
>
> the reason I recommended using as.list (for example) was to respect the
> implied abstraction between the object (of class 'timeSeries') and it's
> representation. Apparently there is a method as.list.timeSeries, and a
> list is something that I am allowed to know about. Your code below
> works, but doesn't respect the (R-level) abstraction the class author
> wants. I don't know whether this is regular practice in the R community,
> but it seems like the right thing to do.
>
> Martin
>
> >
> > v=REAL(val);
> >
> > PROTECT(t2=getAttrib(val,R_DimSymbol));
> >
> > nx=INTEGER(t2)[0];
> > ny=INTEGER(t2)[1];
> >
> > /* Just printing out the matrix
> >*  To understand how I can convert
> >*  data types b/w R and C
> >*/
> >
> > printf("Matrix:\n");
> >
> > for(i=0,j=0;i<(nx*ny);i++,j++) {
> >
> > printf("%.4f ",v[i]);
> >
> > if(j==ny-1) {
> > printf("\n");
> > j=0;
> > }
> >
> > }
> >
> > UNPROTECT(6);
> >
> > return 0;
> >
> > }
> >
> > Regards
> >
> > Abhijit Bera
> >
> >
> > On Wed, Aug 26, 2009 at 12:37 PM, Abhijit Bera  > > wrote:
> >
> > Hi Martin
> >
> > Thanks. I think I got the hang of it. I will try it out and post any
> > more queries I have regarding handling data types onto the mailing
> list.
> >
> > Regards
> >
> > Abhijit Bera
> >
> >
> > On Tue, Aug 25, 2009 at 7:15 PM, Martin Morgan  > > wrote:
> >
> > Abhijit Bera mailto:abhib...@gmail.com>>
> > writes:
> >
> > > Hi
> > >
> > > I think I have asked these questions earlier, but I been able
> > to find
> > > answers from the documentation (which I found poorly written
> > in several
> > > places). Will someone be kind enough to give me answers and
> > enlighten me?
> > > (as in explain with CODE?)
> > >
> > > I want to embed R in my application and use the fPortfolio
> > package for
> > > carrying out risk management computations. Right now I'm
> > reading the
> > > Rmetrics Ebook and trying to convert the various examples into
> > embedded C
> > > code.
> > >
> > > Coming from a strictly C background, I have slight difficulty
> in
> > > comprehending a functional language like R and it gets worse
> > when I try to
> > > embed R into a procedural language like C. So here is a list
> > of my doubts:
> > >
> > > 1) I am very confused on how the lang 1 2 3 4 ... set of
> > functions work. I
> > > haven't found any relevant documentation explaining it
> > clearly. I have a
> > > vague idea but still I cannot understand how I would evaluate
> an R
> > > e

[Rd] R 2.10.0 devel package check error

2009-08-27 Thread John Fox
Dear list members,

I'm getting the following error from R CMD check under Windows only with R
2.10.0 devel:

- snip ---

* installing *source* package 'Rcmdr' ...
** libs
  making DLL ...
gcc -I"c:/R/R-2.10.0dev/include"-O3 -Wall  -std=gnu99 -c ismdi.c -o
ismdi.o
gcc -shared -s -o Rcmdr.dll tmp.def ismdi.o -lRgraphapp
-Lc:/R/R-2.10.0dev/bin -lR
  ... done
** R
** inst
** help
*** installing help indices
Error in cat("\n-- ", f, " --\n\n", sep =
"",  : 
  object 'outcon' not found
* removing 'C:/eclipse/Rcmdr.Rcheck/Rcmdr'

- snip ---

The package does in fact install properly on this system, including the help
files, and I've been unable to track down the source of the problem.

Version and system information:

- snip ---

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = Under development (unstable)
 major = 2
 minor = 10.0
 year = 2009
 month = 08
 day = 26
 svn rev = 49443
 language = R
 version.string = R version 2.10.0 Under development (unstable) (2009-08-26
r49443)

Windows Vista (build 6002) Service Pack 2

Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=Engl
ish_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base

- snip ---

The offending package, Rcmdr 2.5-0, is available on R-Forge.

Any help would be appreciated.

Thanks,
 John

--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox

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


[Rd] Backup ( *~ ) files in R 2.9.2 distribution (PR#13914)

2009-08-27 Thread Frederic . Schutz
The R-2.9.2.tar.gz file, when unpacked, contains a small number of files
ending with an "~" -- usually backup files, which should probably not
find their way into an actual release:

sch...@sib-pc45:~/R/upstream/R-2.9.2$ find . -name \*~
./src/library/base/R/eval.R~
./src/library/base/man/expand.grid.Rd~
./src/library/base/man/with.Rd~
./src/library/graphics/R/rect.R~
./src/library/stats/R/mlm.R~
./src/library/utils/R/de.R~
./src/library/utils/man/combn.Rd~
./src/library/stats4/R/mle.R~
./src/library/stats4/man/profile-methods.Rd~

Frédéric

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


[Rd] Wishlist: specify the border color of boxes in legend() (PR#13913)

2009-08-27 Thread Frederic . Schutz
This is a multi-part message in MIME format.
--040007030503070307040509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I could not find a way to specify the border color of the boxes drawn in
a legend, so that the legend can match exactly the colors of the actual
plot (e.g. in the case of two superimposed histograms which have
different shading and different borders).

Indeed, the legend function seems to hard code the color "black" for the
borders in this call:

 rect2(left = xt, top = yt + ybox/2, dx = xbox, dy = ybox,
   col = fill, density = density, angle = angle,
border = "black")

I worked around this by adding a "border" argument to the function
(which defaults to "black"), and changing the call above. It works for
me; I have looked quickly at the rest of the function to see if there
would be a side effect and did not see any (but I haven't checked
carefully).

This could be a useful improvement of the legend() function; in case the
change described above looks usable, I attach two simple diff files (for
the function itself and the manual page).

Cheers,

Frédéric

--040007030503070307040509
Content-Type: text/x-patch;
 name="legend.R.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="legend.R.diff"

--- legend.R~   2009-03-20 00:05:18.0 +0100
+++ legend.R2009-08-27 11:52:02.0 +0200
@@ -15,8 +15,8 @@
 #  http://www.r-project.org/Licenses/
 
 legend <-
-function(x, y = NULL, legend, fill=NULL, col = par("col"), lty, lwd, pch,
-angle = 45, density = NULL, bty = "o", bg = par("bg"),
+function(x, y = NULL, legend, fill=NULL, col = par("col"), border="black",
+ lty, lwd, pch, angle = 45, density = NULL, bty = "o", bg = par("bg"),
  box.lwd = par("lwd"), box.lty = par("lty"), box.col = par("fg"),
 pt.bg = NA, cex = 1, pt.cex = cex, pt.lwd = lwd,
 xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, adj = c(0, 0.5),
@@ -217,7 +217,7 @@
fill <- rep(fill, length.out = n.leg)
rect2(left = xt, top=yt+ybox/2, dx = xbox, dy = ybox,
  col = fill,
- density = density, angle = angle, border = "black")
+ density = density, angle = angle, border = border)
}
xt <- xt + dx.fill
 }

--040007030503070307040509
Content-Type: text/x-patch;
 name="legend.Rd.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="legend.Rd.diff"

--- legend.Rd~  2009-03-20 00:05:18.0 +0100
+++ legend.Rd   2009-08-27 11:57:28.0 +0200
@@ -8,7 +8,7 @@
 \title{Add Legends to Plots}
 \usage{
 legend(x, y = NULL, legend, fill = NULL, col = par("col"),
-   lty, lwd, pch,
+   border="black", lty, lwd, pch,
angle = 45, density = NULL, bty = "o", bg = par("bg"),
box.lwd = par("lwd"), box.lty = par("lty"), box.col = par("fg"),
pt.bg = NA, cex = 1, pt.cex = cex, pt.lwd = lwd,
@@ -34,6 +34,8 @@
 with the specified colors (or shaded in the specified colors)
 to appear beside the legend text.}
   \item{col}{the color of points or lines appearing in the legend.}
+  \item{border}{the border color for the boxes (used only if
+\code{fill} is specified).}
   \item{lty, lwd}{the line types and widths for lines appearing in the
 legend.  One of these two \emph{must} be specified for line drawing.}
   \item{pch}{the plotting symbols appearing in the legend, either as

--040007030503070307040509--

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


Re: [Rd] Problem with standard generic methods in Matrix package

2009-08-27 Thread Martin Maechler
Dear Sylvain,

> "s" == sloiseau  
> on Wed, 26 Aug 2009 09:37:34 +0200 (CEST) writes:

s> I have posted this message on r-lang, but it is perhaps more appropriate
s> on r-devel:

[[ "r-lang"  what's that ???  ]]

s> ---

s> Hello,

s> I'm puzzled by a problem with call to diag(), rowSums(), rownames() on
s> objects of class "dgtMatrix", created by sparseMatrix() or spMatrix().

s> I use Matrix 0.999375-30.


s> The weird thing is that I don't encounter any problem when I use this
s> functions on the R prompt, or source()-ing a script file; I encounter
s> problems when the code is in a package, installed with R CMD INSTALL, and
s> loaded with library().



s> I have tried to reduce the package to the bare minimum in order to
s> discover the problem, but it continue even when reduced up to a single

s> method, no dependency other than Matrix. The method is defined as:


I think it would still be most efficient,
if you  do  'R CMD build '
and make the   .tar.gz  file available.

Ideally for every reader of this list, from a "public" URL;
alternatively, send it per e-mail as attachment;
if you use correct MIME type, i.e., one of

application/x-tar
application/x-compressed-tar
application/x-gzip

then the file should *not* be filtered out by the mailing list
software.

Best regards,
Martin Maechler, ETH Zurich  (one of the 'Matrix' authors)

s> ---

s> getAdjacentAsSparseMatrix <- function() {

s> adjacents <- sparseMatrix(i=1:10, j=1:10, x=1:10)

s> print(class(adjacents));

s> diagonal <- as.vector(diag(adjacents));

s> if (any(diagonal != 0)) {

s> diagonal[diagonal > 1] <- 1;

s> diag(adjacents) <- diagonal;

s> }

s> return(adjacents);

s> }

s> ---



s> And the Depends field in ./DESCRIPTION :



s> ---

s> Depends: R (>= 2.5.0), Matrix

s> ---



s> I have this outputs:



s> [1] "dgTMatrix"

s> Erreur dans y[1L + 0L:(m - 1L) * (n + 1L)] <- x :

s> types (de S4 a double) incompatibles dans l'ajustement d'affectation de

s> type

>> traceback()

s> 3: diag(adjacents)

s> 2: as.vector(diag(adjacents))

s> 1: getAdjacentAsSparseMatrix(white3)



s> The same thing happens with the method rowSums(), colnames() and
s> rownames(). In brief, it looks as if the generic functions were called,

s> and not the overloaded ones. I can't figure out how to fix that, and will
s> be interested in any pointers.



s> Best,

s> Sylvain

s> __
s> R-devel@r-project.org mailing list
s> 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] Clarifications please.

2009-08-27 Thread Dirk Eddelbuettel

Abhijit,

On 27 August 2009 at 19:29, Abhijit Bera wrote:
| Hi Martin
| 
| Sorry, I made a mistake, I wasn't looking at the syntactic correctness of
| your code, I just followed what you suggested.
| 
| Your method is valid when I want to extract data from a class. I was trying
| to get data from a covariance matrix. I'll put up code in my next mail
| showing how to access the different data types using different methods.

Have you looked RInside which covers your use case 

- accessing an embedded R instance from an outer C++ program
 
- sending data and/or parameters to R,

- evaluating R expressesions

- getting data back from R to the C++ layer

See 

http://dirk.eddelbuettel.com/code/rinside.html 

for more.  Documentation is still sparse, but there are examples, and the
Rcpp classes are very useful for converting a number of basic R types to and
from C++ representations.

Dirk

-- 
Three out of two people have difficulties with fractions.

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


Re: [Rd] R 2.10.0 devel package check error

2009-08-27 Thread Prof Brian Ripley

AFAICS that is already fixed (r49467).

It was a Windows-only problem when building just chm help - I suspect 
the latter did not work in your package.


I should perhaps remind people that R-devel is 'unstable' and as we 
work on the help system it is likely to be particularly unstable on 
Windows (since there are features such as this one that are only 
exercised there).


Reports on R-devel are welcome, but most useful if they are about 
things that have persisted for a few days.


Brian

On Thu, 27 Aug 2009, John Fox wrote:


Dear list members,

I'm getting the following error from R CMD check under Windows only with R
2.10.0 devel:

- snip ---

* installing *source* package 'Rcmdr' ...
** libs
 making DLL ...
gcc -I"c:/R/R-2.10.0dev/include"-O3 -Wall  -std=gnu99 -c ismdi.c -o
ismdi.o
gcc -shared -s -o Rcmdr.dll tmp.def ismdi.o -lRgraphapp
-Lc:/R/R-2.10.0dev/bin -lR
 ... done
** R
** inst
** help
*** installing help indices
Error in cat("\n-- ", f, " --\n\n", sep =
"",  :
 object 'outcon' not found
* removing 'C:/eclipse/Rcmdr.Rcheck/Rcmdr'

- snip ---

The package does in fact install properly on this system, including the help
files, and I've been unable to track down the source of the problem.

Version and system information:

- snip ---

Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = Under development (unstable)
major = 2
minor = 10.0
year = 2009
month = 08
day = 26
svn rev = 49443
language = R
version.string = R version 2.10.0 Under development (unstable) (2009-08-26
r49443)

Windows Vista (build 6002) Service Pack 2

Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=Engl
ish_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252

Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base

- snip ---

The offending package, Rcmdr 2.5-0, is available on R-Forge.

Any help would be appreciated.

Thanks,
John

--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox

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



--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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


Re: [Rd] Problem with standard generic methods in Matrix package

2009-08-27 Thread Sylvain Loiseau

Hello,


I think it would still be most efficient,
if you  do  'R CMD build '
and make the   .tar.gz  file available.

Ideally for every reader of this list, from a "public" URL;
alternatively, send it per e-mail as attachment;
if you use correct MIME type, i.e., one of


Ok, here is the minimal package producing the error :

http://panini.u-paris10.fr/~sloiseau/test_1.0.tar.gz

I have :

library(test)

getAdjacentAsSparseMatrix()

[1] "dgCMatrix"
attr(,"package")
[1] "Matrix"
Erreur dans y[1L + 0L:(m - 1L) * (n + 1L)] <- x :
   types (de S4 a double) incompatibles dans l'ajustement d'affectation de
type

Thanks!
Sylvain

--
Sylvain Loiseau
slois...@ens-lsh.fr

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


Re: [Rd] R 2.10.0 devel package check error

2009-08-27 Thread John Fox
Dear Brian,

Because this problem surfaced only with the Rcmdr package, and other
packages checked without error, I thought that the problem was in the
package. Also R CMD INSTALL Rcmdr built the chm help pages correctly, as far
as I can see.

Anyway, I'll try again in a few days.

Thank you for the information (and the admonishment).

John


> -Original Message-
> From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk]
> Sent: August-27-09 11:53 AM
> To: John Fox
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] R 2.10.0 devel package check error
> 
> AFAICS that is already fixed (r49467).
> 
> It was a Windows-only problem when building just chm help - I suspect
> the latter did not work in your package.
> 
> I should perhaps remind people that R-devel is 'unstable' and as we
> work on the help system it is likely to be particularly unstable on
> Windows (since there are features such as this one that are only
> exercised there).
> 
> Reports on R-devel are welcome, but most useful if they are about
> things that have persisted for a few days.
> 
> Brian
> 
> On Thu, 27 Aug 2009, John Fox wrote:
> 
> > Dear list members,
> >
> > I'm getting the following error from R CMD check under Windows only with
R
> > 2.10.0 devel:
> >
> > - snip ---
> >
> > * installing *source* package 'Rcmdr' ...
> > ** libs
> >  making DLL ...
> > gcc -I"c:/R/R-2.10.0dev/include"-O3 -Wall  -std=gnu99 -c ismdi.c
-o
> > ismdi.o
> > gcc -shared -s -o Rcmdr.dll tmp.def ismdi.o -lRgraphapp
> > -Lc:/R/R-2.10.0dev/bin -lR
> >  ... done
> > ** R
> > ** inst
> > ** help
> > *** installing help indices
> > Error in cat("\n-- ", f, " --\n\n", sep
=
> > "",  :
> >  object 'outcon' not found
> > * removing 'C:/eclipse/Rcmdr.Rcheck/Rcmdr'
> >
> > - snip ---
> >
> > The package does in fact install properly on this system, including the
> help
> > files, and I've been unable to track down the source of the problem.
> >
> > Version and system information:
> >
> > - snip ---
> >
> > Version:
> > platform = i386-pc-mingw32
> > arch = i386
> > os = mingw32
> > system = i386, mingw32
> > status = Under development (unstable)
> > major = 2
> > minor = 10.0
> > year = 2009
> > month = 08
> > day = 26
> > svn rev = 49443
> > language = R
> > version.string = R version 2.10.0 Under development (unstable)
(2009-08-26
> > r49443)
> >
> > Windows Vista (build 6002) Service Pack 2
> >
> > Locale:
> >
>
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=Engl
> > ish_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252
> >
> > Search Path:
> > .GlobalEnv, package:stats, package:graphics, package:grDevices,
> > package:utils, package:datasets, package:methods, Autoloads,
package:base
> >
> > - snip ---
> >
> > The offending package, Rcmdr 2.5-0, is available on R-Forge.
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > John
> >
> > --
> > John Fox, Professor
> > Department of Sociology
> > McMaster University
> > Hamilton, Ontario, Canada
> > web: socserv.mcmaster.ca/jfox
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> 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] ARM v7/Linux Port/cross-compile?

2009-08-27 Thread Jonathan Wilner
Hi, 

Has anyone succeeded in cross-compiling R to Linux on an ARM CPU? If so, can 
you share a little about your toolchain & build process? 

Thanks! 

[[alternative HTML version deleted]]

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


Re: [Rd] ARM v7/Linux Port/cross-compile?

2009-08-27 Thread Simon Urbanek


On Aug 27, 2009, at 5:37 PM, Jonathan Wilner wrote:


Hi,

Has anyone succeeded in cross-compiling R to Linux on an ARM CPU?


Yes (although that questions leaves a lot of room for interpretation).



If so, can you share a little about your toolchain & build process?



It was fairly straight-forward to build R (like any other cross- 
compilation). The tricky part is to install packages (if you are truly  
cross-compiling on another architecture) which I solved by using multi- 
arch R (which contains both arm and the host architecture) and cross- 
compiling only the binaries (i.e. only packages with native code).  
That could probably be simplified, but I didn't have the time to do  
that.


Cheers,
Simon

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


[Rd] R CMD check does not recognize S4 functions inside other functions?

2009-08-27 Thread Giles Hooker

I am developing a new R package and am now checking it for submission to
CRAN.

The some functions in the package make use of the sparse matrix routines
in the package 'Matrix'.

When these are loaded in R, they create no problems.

However, when running R CMD check, I run into the following error in 
executing the examples in a .rd file:


>   DD = Matrix(diag(1,200),sparse=TRUE)
>   tDD = t(DD)
>
> fres = FitMatchOpt(coefs=coefs,which=2,pars=pars,proc)
Error in t.default(DD) : argument is not a matrix
Calls: FitMatchOpt -> t -> t.default
Execution halted

The first two lines of the function FitMatchOpt are

  DD = Matrix(diag(1,200),sparse=TRUE)
  tDD = t(DD)

These were fine when given in the examples section of the .rd file 
directly. However, when defined within a function in the package, the 
lines cause an error.


Sparse matrices improve the computational efficiency of the routines I 
am developing and I would like to use them. But I'm not sure how I can 
get around this error.


Many thanks,

Giles Hooker

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