Re: [Rd] Makevars or congiure for multi platforms
2008/6/7 <[EMAIL PROTECTED]>: > > Message: 11 > Date: Sat, 7 Jun 2008 03:38:23 +0900 > From: "Tadashi Kadowaki" <[EMAIL PROTECTED]> > Subject: [Rd] Makevars or congiure for multi platforms > To: r-devel@r-project.org > Message-ID: ><[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Dear all, > > As previously submitted, I wrote an extending pdf device to embed > pop up text and web links. > (Patches are available at http://pdf2.r-forge.r-project.org/patches) > > Now, I'm making a library version of the pdf device. > However, with my skill, I'm not sure about writing Makevars or configure file > for multi platforms. A following line in Makevars works on my mac, > - > PKG_CFLAGS=-I/Library/Frameworks/R.framework/PrivateHeaders -DHAVE_CONFIG_H > - > (Note that the PrivateHeaders directory contains Fileio.h and Defn.h) > > My question is, > How do I write Makevars or congiure for Unix/Linux and Windows? > I would like to support those platforms in my library. You could try looking into a package that has configure, configure.win and has built binaries for macosX and windows. Try the package 'rgl' on CRAN, for example. Hoping this helps, L. > Regards, > > Tadashi Kadowaki > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Add 'postinstall' hook to R CMD INSTALL ?
Brian,
On 6 June 2008 at 07:33, Dirk Eddelbuettel wrote:
|
| On 6 June 2008 at 13:13, Prof Brian Ripley wrote:
| | > On 6 June 2008 at 11:34, Prof Brian Ripley wrote:
| | > | Isn't this what Type: Frontend is for? That gives you complete control
| | > | and would seem appropriate for both of your examples.
| | >
| | > Interesting. But the R Extensions manual says
| | >
| | > 1.10.1 Frontend
| | > ---
| | >
| | > This is a rather general mechanism, designed for adding new front-ends
| | > such as the *gnomeGUI* package. If a `configure' file is found in the
| | > top-level directory of the package it is executed, and then if a
| | > `Makefile' is found (often generated by `configure'), `make' is called.
| | > If `R CMD INSTALL --clean' is used `make clean' is called. No other
| | > action is taken.
| | >
| | > I am talking about the need for 'other action' such as 'make install',
say.
| | >
| | > Are you suggesting I shoehorn what I want done into the main 'make'
target ?
| |
| | Yes. I don't see it as 'shoehorn' -- it is the install step.
|
| I have to think about this. I was envisioning a degree of freedom between
| 'make' and 'make install'. I may need some optionality here.
|
| Anyway -- thanks for the suggestions. It is indeed very close to what I had
| asked for.
Thanks again for the gnomeGui suggestion. I looked at it and it comes close
but offer no cigar yet. So looking at the code in $R_HOME/bin/INSTALL:
if test "$Type" = "Frontend" ; then
message "Installing *Frontend* package '${pkg_name}' ..."
if ${preclean}; then
${MAKE} clean
fi
if ${use_configure} && test -x ./configure ; then
eval ${configure_vars} ./configure ${configure_args}
if test ${?} -ne 0; then
error "configuration failed for package '${pkg_name}'"
do_exit_on_error
fi
fi
if test -f ./Makefile ; then
${MAKE}
if test ${?} -ne 0; then
error "make failed for package '${pkg_name}'"
do_exit_on_error
fi
if ${clean}; then
${MAKE} clean
fi
return
fi
return
fi
it is clear that the 'make install' step Jeff and I have asked about is not
there.
Seeing how behaviour in the 'Frontend' case can be conditioned on flags like
--preclean, would there be objections to a patch implementing a new option,
say, --frontendinstall (or something similar that is shorter and more
expressive) that would, if set, call '${MAKE} install' before the 'make
clean' step ?
Better still, and in order to make things more autoMAGIC so that we can use
features like update.packages(), could the 'make install' case be conditional
on a) the 'Type = Frontend' choice in DESCRIPTION _and_ b) a top-level script
frontend-install in the package? So instead of an user the user had to
choose, could we just run this for her a la
if test -f ./frontend-install; then
./frontend-install
## alternatively, run ${MAKE} install
if test ${?} -ne 0; then
error "make install failed for package '${pkg_name}'"
do_exit_on_error
fi
Thirdly, I don't really see why we can't just run 'make install'
unconditionally. That may need a minor patch to gnomeGUI to move the
(somewhat non-standard) 'install' target out of the 'make all' dependencies.
I'd be happy to work on a complete patch that also updates the discussion in
the R Extensions manual, R Admin manual and the INSTALL help text, plus
whereever else INSTALL is documented.
Regards, 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] Makevars or congiure for multi platforms
Hi, Laurent and Tobias Thanks a lot. I could make configure script and upload it to r-forge. https://r-forge.r-project.org/projects/pdf2/ It still works only on mac by default. For Linux and Windows, it needs additional option like - R CMD INSTALL --configure-vars="R_INTERNAL_HEADER_DIR=/path/to/src/include" pdf2/pkg - ,where /path/to/src/include is the directory in the R source. I didn't check it for Linux and Windows... Regards, Tadashi Kadowaki 2008/6/8 Laurent Gautier <[EMAIL PROTECTED]>: > 2008/6/7 <[EMAIL PROTECTED]>: >> >> Message: 11 >> Date: Sat, 7 Jun 2008 03:38:23 +0900 >> From: "Tadashi Kadowaki" <[EMAIL PROTECTED]> >> Subject: [Rd] Makevars or congiure for multi platforms >> To: r-devel@r-project.org >> Message-ID: >><[EMAIL PROTECTED]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Dear all, >> >> As previously submitted, I wrote an extending pdf device to embed >> pop up text and web links. >> (Patches are available at http://pdf2.r-forge.r-project.org/patches) >> >> Now, I'm making a library version of the pdf device. >> However, with my skill, I'm not sure about writing Makevars or configure file >> for multi platforms. A following line in Makevars works on my mac, >> - >> PKG_CFLAGS=-I/Library/Frameworks/R.framework/PrivateHeaders -DHAVE_CONFIG_H >> - >> (Note that the PrivateHeaders directory contains Fileio.h and Defn.h) >> >> My question is, >> How do I write Makevars or congiure for Unix/Linux and Windows? >> I would like to support those platforms in my library. > > You could try looking into a package that has configure, configure.win > and has built binaries for macosX and windows. Try the package 'rgl' > on CRAN, for example. > > > Hoping this helps, > > > L. > > > >> Regards, >> >> Tadashi Kadowaki >> >> >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slot(obj, "nosuch") documentation question
Paul Roebuck wrote:
Using slot() on object (or "@") and using a nonexistent
slotname returns an error (see example code).
R> setClass("foobar", representation=list(a="numeric"))
[1] "foobar"
R> foobar <- new("foobar", a=5)
R> [EMAIL PROTECTED]
[1] 5
R> [EMAIL PROTECTED]
Error: no slot of name "b" for this object of class "foobar"
The details section of manpage has a paragraph that
seems to agree with above:
Unlike attributes, slots are not partially matched,
and asking for (or trying to set) a slot with an
invalid name for that class generates an error.
But then the last paragraph in that same section seems to
suggest otherwise.
Currently the @ extraction operator and slot function
do no checking, neither that object has a formal class
nor that name is a valid slot name for the class. (They
will extract the attribute of the given name if it
exists from any R object.) The replacement forms do
check (at least if check=TRUE).
Are these two paragraphs not in partial conflict with each
other?
No, but a little more detail in the documentation would have been
helpful. See my previous thread on this list: the methods
documentation is getting a major rewrite at the moment.
What's guaranteed is that [EMAIL PROTECTED] <- 1 will be disallowed if "b" is
not a valid slot name or the right hand side is not coerceable to the
appropriate class. So as long as nobody cheats, only valid slot names
will be found and not finding a slot of an invalid name generates an error.
However.
For various reasons, slots in R were implemented as attributes, and in
the immediate future seem likely to remain so. And, for now, there is
no guarantee that code has not gone around assigning attributes with
other names.
The access function @ or slot() doesn't go off to the class definition
to check the name, so once such an attribute is inserted, it looks like
a "slot". But you still will get an error assigning a value, because
that computation _does_ check validity. All this is in pursuit of
efficiency, arguing that slot access tends to happen more often than
replacement.
The following extension of your example illustrates:
> setClass("foobar", representation=list(a="numeric"))
[1] "foobar"
> foobar <- new("foobar", a=5)
> [EMAIL PROTECTED]
[1] 5
> [EMAIL PROTECTED]
Error: no slot of name "b" for this object of class "foobar"
> attr(foobar, "b") <- 10
> [EMAIL PROTECTED]
[1] 10
> [EMAIL PROTECTED] <- 1
Error in checkSlotAssignment(object, name, value) :
"b" is not a slot in class "foobar"
I had initially expected (my initial bottom-up
quick glance only read last paragraph) to get NULL from
invalid slotname.
This is in reference to writing method that might be
passed an object created by previous version of software,
and new slots were added to class in later revisions.
For such situations, is the norm then to do
"slotNames(obj) %in% " prior to accessing any
slotname from extended class?
Dangerous practice. I presume what happens is that objects are saved,
then restored after the class has been redefined. Restoring the old
object creates an invalid object of the class. You really should follow
the restore by "fixing" any out of date objects.
It would be nice if R had versioning software that did some of this
automatically, although in general it's a tough problem.
Perhaps other users who have encountered the problem of revising classes
might comment on what their practice is. Managing changing class
definitions is an interesting and important topic.
John
TIA
R version 2.7.0 Patched (2008-06-04 r45830)
--
SIGSIG -- signature too long (core dumped)
__
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] R CMD CHECK WARNING inappropriate for S4 method?
The package 'graph' defines classes graph and graphNEL (extending graph) and a union,graph,graph-method. These are all exported and fully documented. The package 'GSEABase' Imports: graph and importClassesFrom(graph, graphNEL). GSEABase defines methods on union for its own classes (not graph / graphNEL), and has exportMethods(union). union,graph,graph-method is not used in GSEABase. R version 2.8.0 Under development (unstable) (2008-06-08 r45879) reports from R CMD CHECK GSEABase * checking for missing documentation entries ... WARNING Undocumented S4 methods: generic 'union' and siglist 'graph,graph' I guess union,graph,graph-method is exposed to the user indirectly by its import along with the graph class and export along with the newly-defined union methods. It would seem inappropriate to document union,graph,graph-method in GSEABase. Making GSEABase Depend: graph rather than Import: graph does not help. Any guidance welcome. Thanks, Martin -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slot(obj, "nosuch") documentation question
John Chambers <[EMAIL PROTECTED]> writes: > Paul Roebuck wrote: >> Using slot() on object (or "@") and using a nonexistent >> slotname returns an error (see example code). [snip] >> This is in reference to writing method that might be >> passed an object created by previous version of software, >> and new slots were added to class in later revisions. >> >> For such situations, is the norm then to do >> "slotNames(obj) %in% " prior to accessing any >> slotname from extended class? >> > Dangerous practice. I presume what happens is that objects are saved, > then restored after the class has been redefined. Restoring the old > object creates an invalid object of the class. You really should > follow the restore by "fixing" any out of date objects. > > It would be nice if R had versioning software that did some of this > automatically, although in general it's a tough problem. > > Perhaps other users who have encountered the problem of revising > classes might comment on what their practice is. Managing changing > class definitions is an interesting and important topic. The not completely satisfactory solution in the Bioconductor package Biobase is classes Versioned (a 'mix-in' class to provide versioning information and dispatch) and Versions (to represent version strings), plus generics isVersioned, isCurrent, classVersion, classVersion<- for accessing Versioned, and updateObject for providing a common interface to the update operation. Versioned is a class with slot .__classVersion__ that the developer populates with a vector of Version objects. isCurrent is meant to be the main entry point for assessing version, and compares the class version of the object with the class version recorded in the class definition. It also grandfathers in instances that existed before Versioned itself was added to the class by checking that the object has its S4 bit set, and that the instance is actually versioned. The developer is expected to write updateObject methods that know how to update from previous versions to the current version, and callNextMethod to delegate responsibility to inherited methods (including a default that tries to create a new instance by copying slots from the current object into a newly created instance). There are several complexities. isCurrent has to make decisions about the current-ness of slot content (much as validObject does). Inheritance means that only a portion of the class hierarchy might be out-of-date so length(Versions) > 1 is the norm. Methods are not associated with classes, so in a sense and for reproducibility 'isCurrent' might mean that the object was created with the same version of R and relevant packages as are currently in use. updateObject would really like to have a semantic and method dispatch like validObject, where each updateObject method takes responsibility for updating only the portion of the class that the method is responsible for. There are a number of aspects that are unsatisfactory about the implementation. The developer has to manage class version numbering (there's no hashing, say, of the class definition to automatically register a new class; hashing is more complicated than at first sight because components of the class can be out of date), including an awkward way of capturing versions of inherited classes. Out-of-date objects are not detected when loaded, but typically when a method fails (and then the user writes to the bioc mailing list and is told to use updateObject; key methods in Biobase check for class version, but this is too expensive for every operation and many packages outside Biobase make use of Biobase classes without checking version information). Writing updateObject methods is challenging, in part because updateObject uses 'standardGeneric' for dispatch and the developer has to manage both updating the object and dispatching to appropriate 'next' methods. >From the user perspective, updateObject seems to have been quite successful -- it provides a clean way for the user to solve a problem, once it's been diagnosed. Improvements on an iteration of this might (a) develop a default updateObject method that 'did the right thing' more reliably, much as 'initialize,ANY-method' does. In fact, the current updateObject,ANY-method does seem to be moderately successful at this. (b) generalize the 'validObject' dispatch model and use that to more clearly delineate the responsibilities of updateObject methods (which currently have to be update their part of the object and dispatch to the 'next' method and slots, if appropriate). (c) check object version on load, which would require a change to R itself, or some unique discipline on the part of objects from the package. Martin > John >> >> TIA >> >> >> R version 2.7.0 Patched (2008-06-04 r45830) >> >> -- >> SIGSIG -- signature too long (core dumped) >> >> __ >> R-devel@r-project.org mail
[Rd] SHLIB_CXXLDFLAGS needs quotes on Solaris section of admin manual.
In the admin manual, there is some information about flags etc for Solaris: CC="cc -xc99" CPPFLAGS=-I/opt/csw/include CFLAGS="-O -xlibmieee" F77=f95 FFLAGS=-O4 CXX=CC CXXFLAGS=-O FC=f95 FCFLAGS=$FFLAGS LDFLAGS=-L/opt/csw/lib SHLIB_CXXLDFLAGS=-G -lCstd Where as the CC command is quoted, the SHLIB_CXXLDFLAGS one is not. Failure to put quotes around it results in configure script aborting. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SHLIB_CXXLDFLAGS needs quotes on Solaris section of admin manual.
Dr. David Kirkby wrote: In the admin manual, there is some information about flags etc for Solaris: CC="cc -xc99" CPPFLAGS=-I/opt/csw/include CFLAGS="-O -xlibmieee" F77=f95 FFLAGS=-O4 CXX=CC CXXFLAGS=-O FC=f95 FCFLAGS=$FFLAGS LDFLAGS=-L/opt/csw/lib SHLIB_CXXLDFLAGS=-G -lCstd Where as the CC command is quoted, the SHLIB_CXXLDFLAGS one is not. Failure to put quotes around it results in configure script aborting. i.e. I think it should read: SHLIB_CXXLDFLAGS="-G -lCstd" rather than SHLIB_CXXLDFLAGS=-G -lCstd __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eigenvector dimname convention?
What are reasonable conventions for dimnames for eigenvectors? The standard 'eigen' function discards dimnames. If a matrix X is symmetric (and rownames = colnames), it seems more sensible to assign rownames(eigen(X)$vectors) <- rownames(X). The eigenvalues seem different, so I'm inclined to assign names like ev1, ev2, ..., to the eigenvectors and use those names for the columns of eigen(...)$vectors. However, this analysis does not apply if rownames != colnames. What should be done in that case? The 'solve' function uses a convention that might help here: tst <- matrix(1:4, 2, dimnames=list(LETTERS[1:2], letters[3:4])) > tst c d A 1 3 B 2 4 solve(tst) AB c -2 1.5 d 1 -0.5 Tentative conclusion: If rownames != colnames (or the matrix is not symmetric), then dimnames(eigen(X)$vectors) = dimnames(X). That's because X = (vectors %*% values %*% solve(vectors)). If desired, the eigenvalues can be assigned names matching colnames(X). Does this make sense? I ask, because I'm writing a function 'EIGEN' as a wrapper for 'eigen' that tries to preserve dimnames. This analysis suggests that how dimnames are assigned is at least partly a matter of convention rather than mathematics. Thanks, Spencer Graves __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makevars or congiure for multi platforms
Private headers are just that, private. They are not intended to be available to packages, and not installed by the standard R makefiles on either Unix-alikes or Windows. I don't see it documented that they are available on MacOS X, and will leave it to that platform's maintainers as to why they have been installed on that platform. You need to rewrite your code to use only documented headers and entry points if you intend to distribute it. On Mon, 9 Jun 2008, Tadashi Kadowaki wrote: Hi, Laurent and Tobias Thanks a lot. I could make configure script and upload it to r-forge. https://r-forge.r-project.org/projects/pdf2/ It still works only on mac by default. For Linux and Windows, it needs additional option like - R CMD INSTALL --configure-vars="R_INTERNAL_HEADER_DIR=/path/to/src/include" pdf2/pkg - ,where /path/to/src/include is the directory in the R source. I didn't check it for Linux and Windows... Regards, Tadashi Kadowaki 2008/6/8 Laurent Gautier <[EMAIL PROTECTED]>: 2008/6/7 <[EMAIL PROTECTED]>: Message: 11 Date: Sat, 7 Jun 2008 03:38:23 +0900 From: "Tadashi Kadowaki" <[EMAIL PROTECTED]> Subject: [Rd] Makevars or congiure for multi platforms To: r-devel@r-project.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Dear all, As previously submitted, I wrote an extending pdf device to embed pop up text and web links. (Patches are available at http://pdf2.r-forge.r-project.org/patches) Now, I'm making a library version of the pdf device. However, with my skill, I'm not sure about writing Makevars or configure file for multi platforms. A following line in Makevars works on my mac, - PKG_CFLAGS=-I/Library/Frameworks/R.framework/PrivateHeaders -DHAVE_CONFIG_H - (Note that the PrivateHeaders directory contains Fileio.h and Defn.h) My question is, How do I write Makevars or congiure for Unix/Linux and Windows? I would like to support those platforms in my library. You could try looking into a package that has configure, configure.win and has built binaries for macosX and windows. Try the package 'rgl' on CRAN, for example. Hoping this helps, L. Regards, Tadashi Kadowaki __ 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: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issue with NA value and Octave compatibility
Dear R developers, I'm an Octave developer in the process of implementing a single precision type in Octave and I have an issue with the NA value. The choice of NA value in Octave was made a few years back so that the high word of the NA value was 0x7ff0 and the low word was 0x07A2 for compatibility with R and to ease any possible issue with the exchange of data files between Octave and R. However, now that I'm in the process of implementing the single precision type I have a problem with this choice for the NA value as the above when cast to a float results in the loss of the 0x7A2 value creating a positive Infinity in IEE754, and so conversion of the NA values between double and float with the above value does not work. I have several possible choices of how to treat this, but as the reason for the choice of Octave's NA value was made for compatibility with R, the choice I'll make might very well be determined by how the R developers react to any changes that Octave makes in this direction. I can't realistically wrap the double and float types in Octave and overload the assignment operators to handle the assignment of a float to a double and visa versa as this would completely replace the underlying data types in Octave. Its also impossible to trap everywhere where a double might be assigned to a float and special case NA values as there are just too many places that might occur. I'm therefore assuming that I have to replace Octave's internal representation of the NA value to allow easy conversion of the NA value between double and floats. This can be done by replacing the NA value with one that has zeros in the lower 19 bits of the mantissa of the double, so that the cast from a double to float and visa versa works correctly. For example using 0x7FF840F4 and 0x4000 for the low and high word of the double NA value. and 0x7FC207A2 for the float NA value works. However then I have an issue of exchange of NA values with R and with older versions of Octave. Its easy enough to check for old NA values in files when reading and alter them to the new NA values. So forward compatibility with older versions of Octave and from R to Octave would be ok. However, the reverse is not true. Actually saving the with the old NA value is equally possible and would allow full compatible with older versions of Octave and with R. The downside is that there are many places I'd have to make a copy of the data when saving to allow this (for example saving to HDF files), and so I'd prefer not to have to do this if possible. As backwards compatibility is the smaller concern and self correcting with time, if R was to also accept the an additional possible NA value such as 0x7FF840F4/0x4000, at least when loading files then compatibility of the NA value between Octave and R could be maintained and I wouldn't have to pay the penalty of making a copy of the data to treat the NA values. Would the R developers be willing to make such a change in R? If not I will maintain the R compatible NA value in Octave's output and pay the performance penalty within Octave for this. In any case if R intends at some point to support a single precision type you will come across the same issue. Regards David __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R and Gnumeric
Hi, I just read the "Embedding R in Gnumeric" idea at http://www.r-project.org/SoC08/ideas.html. On my side, I intend to add as many statistics related plot types to the current gnumeric charting engine as possible. We already have boxplots and partial support for histograms. My immediate plans are to finish the histogram code and add probability plots (http://bugzilla.gnome.org/show_bug.cgi?id=500168) during the summer if time permits (importing some code from R). For the future, I see two options: either add all necessary plot types to the gnumeric charting engine or embedding R charts directly using either a new SheetObject class or the goffice component system (which would allow inserting these charts in abiword as well). One other totally unrelated thing. We got recently a bug report about an incorrect R squared in gnumeric regression code (http://bugzilla.gnome.org/show_bug.cgi?id=534659). R (version 2.7.0) give the same result as Gnumeric as can be seen below: > mydata <- read.csv(file="data.csv",sep=",") > mydata X Y 1 1 2 2 2 4 3 3 5 4 4 8 5 5 0 6 6 7 7 7 8 8 8 9 9 9 10 > summary(lm(mydata$Y~mydata$X)) Call: lm(formula = mydata$Y ~ mydata$X) Residuals: Min 1Q Median 3Q Max -5.8889 0.2444 0.5111 0.7111 2.9778 Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) 1.5556 1.8587 0.837 0.4303 mydata$X 0.8667 0.3303 2.624 0.0342 * --- Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1 Residual standard error: 2.559 on 7 degrees of freedom Multiple R-squared: 0.4958, Adjusted R-squared: 0.4238 F-statistic: 6.885 on 1 and 7 DF, p-value: 0.03422 > summary(lm(mydata$Y~mydata$X-1)) Call: lm(formula = mydata$Y ~ mydata$X - 1) Residuals: Min 1Q Median 3Q Max -5.5614 0.1018 0.3263 1.6632 3.5509 Coefficients: Estimate Std. Error t value Pr(>|t|) mydata$X 1.1123 0.1487 7.481 7.06e-05 *** --- Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1 Residual standard error: 2.51 on 8 degrees of freedom Multiple R-squared: 0.8749, Adjusted R-squared: 0.8593 F-statistic: 55.96 on 1 and 8 DF, p-value: 7.056e-05 I am unable to figure out what this 0.8749 value might represent. If it is intended to be the Pearson moment, it should be 0.4958, and if it is the coefficient of determination, I think the correct value would be 0.4454 as given by Excel. It's of course nice to have the same result in R and Gnumeric,but it would be better if this result was accurate (if it is, we need some documentation fix). Btw, I am not a statistics expert at all. Best regards, Jean Brefort __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-code embedded in VBE -- Type mismatch errors
Pietro, [EMAIL PROTECTED] wrote: > Hello, > > I am trying to embed R-code inside VB for Excel (probably a perverse > endeavour anyway) and I am running into difficulties, especially when > passing vectors back and forth between the two environments. > > (1) I am using the RExcel package. There is a mailing list for RExcel where this should be discussed. Please re-post your message to rcom-l. Please be sure to browse the list archives first. Have a look at the RExcel documentation for sources of information. Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
