Re: [Rd] R-devel does not compile under FreeBSD-7.0 CURRENT [SOLVED]
I tried todays R-devel (2006-11-30) with FreeBSD-7.0 CURRENT and it seems, that compiling with 'make && make install' is ok again. Thank you very much, Rainer Hurling Prof Brian Ripley wrote: > As I said to you privately, I believe this to be a make issue: does GNU > make work? We don't guarantee R to work with other makes (although it > usually does). > > My guess is that the problem is the missing .m in the .SUFFIXES list > in Makeconf.in, but Solaris make and GNU make see no problem and it > looks like a make bug to me. I've added the suffix, so please try the > current version. > > (This seems to be related to adding ObjC support which is apparently > currently incomplete.) > > On Wed, 29 Nov 2006, Rainer Hurling wrote: > >> I am not able to compile R-devel 2006-11-28 under FreeBSD-7.0 CURRENT. >> After running ./configure script 'make' stops with the following error >> message: >> >> -- >> #make >> gcc -I. -I./src/include -I./src/include -I/usr/local/include >> -DHAVE_CONFIG_H -g -O2 -c -o .m.o >> gcc: No input files specified >> *** Error code 1 >> >> Stop in /usr/local/R-devel. >> # >> -- >> >> I attached configure messages. If wanted I can send complete >> config.log (460 kByte). >> >> Are their any ideas about what is going wrong? If I could help with >> more information or with testing, please let me know. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printing coefficients with text
> "RossB" == Ross Boylan <[EMAIL PROTECTED]> > on Thu, 30 Nov 2006 12:17:55 -0800 writes: RossB> I want to print the coefficient estimates of a model RossB> in a way as consistent with other output in R as RossB> possible. stats provides the printCoefmat function RossB> for doing this, but there is one problem. I have an RossB> additional piece of textual information I want to put RossB> on the line with the other info on each coefficient. that's not a real problem, see below RossB> The documentation for printCoefmat says the first RossB> argument must be numeric, which seems to rule this out. it does say that (it says "x: a numeric matrix like object" which includes data frames with factors) but you are right that it does preclude a column of "character". RossB> I just realized I might be able to cheat by inserting RossB> the text into the name of the variable (fortunately RossB> there is just one item of text). I think that's in RossB> the names of the matrix given as the first argument RossB> to the function. yes; it's the rownames(); i.e., you'd do something like rownames(myx) <- paste(rownames(myx), format(mytext_var))) which seems simple enough to me, but it only works when the "text" is the first column RossB> Are there any better solutions? Obviously I could RossB> just copy the method and modify it, but that creates RossB> duplicate code and loses the ability to track future RossB> changes to printCoefmat. As original author of printCoefmat(), I'm quite willing to accept and incorporate a patch to the current function definition (in https://svn.r-project.org/R/trunk/src/library/R/anova.R), if it's well written. As a matter of fact, I think already see how to generalize printCoefmat() to work for the case of data frame with character columns [I would not want a character matrix however; since that would mean going numeric -> character -> numeric -> formatting (i.e character) for the 'coefficients' themselves]. Can you send me a reproducible example? or at least an *.Rda file of a save()d such data frame? RossB> Thanks. Ross Boylan You're welcome, Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order of levels in interaction()
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Thu, 30 Nov 2006 21:48:35 + (GMT) writes:
BDR> On Thu, 30 Nov 2006, Deepayan Sarkar wrote:
>> Hi,
>>
>> ?interaction says:
>>
>> See Also:
>>
>> 'factor'; ':' where 'f:g' is the similar to
>> 'interaction(f, g, sep=":")' when 'f' and 'g' are
>> factors.
>>
>> This is not quite true (or maybe 'similar' is the
>> operative word), since:
>>
>>> f <- factor(1:3); g <- factor(letters[1:3])
>>> levels(f:g)
>> [1] "1:a" "1:b" "1:c" "2:a" "2:b" "2:c" "3:a" "3:b" "3:c"
>>> levels(interaction(f, g, sep = ":"))
>> [1] "1:a" "2:a" "3:a" "1:b" "2:b" "3:b" "1:c" "2:c" "3:c"
>>
>> Note the different order of the levels. I like the order
>> in f:g better (and at least one other person agrees [1]
>> ), but I also want the flexibility of having a 'sep'
>> argument. Would it be possible to change interaction to
>> allow this? A simple fix that makes interaction behave
>> like ":" is to replace
BDR> No, for it also says
BDR> The levels are ordered so the level of the first
BDR> factor varies fastest, then the second and so on. This
BDR> is the reverse of lexicographic ordering, and differs
BDR> from ':'. (It is done this way for compatibility with S.)
BDR> and reversing it would break things. (It does, I tried
BDR> it a while back.)
yes, indeed {{ and Deepayan should have ... :-) .. }}
But instead of having Deepayan and other users write their own
customized version of interaction() and having interaction2()
end up in one of those CRAN packages ( ;-} ), we could add a new
argument to interaction() which allows the new behavior - not
active by default, of course.
I'm happy to do this; the only question remaining is how the
argument should be called, and if it's sufficient to have it
logical, or if there are more variations that should be
considered (I think not).
My quick proposals (name and default):
reverse = FALSE
orderFirst = FALSE
>> as.vector(outer(l, lvs, paste, sep = sep))
>>
>> with
>>
>> as.vector(t(outer(l, lvs, paste, sep = sep)))
>>
>> in interaction.
>>
>> -Deepayan
>>
>> [1]
>> http://tolstoy.newcastle.edu.au/R/help/06/08/32638.html
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] promptClass misses methods
> "RossB" == Ross Boylan <[EMAIL PROTECTED]>
> on Thu, 30 Nov 2006 22:29:06 -0800 writes:
RossB> I've had repeated problems with promptClass missing
RossB> methods, usually telling me a class has no methods
RossB> when it does.
RossB> In my current case, I've defined an S4 class
RossB> "mspathCoefficients" with a print method
RossB> setMethod("print", signature(x="mspathCoefficients"),
RossB> function(x, ...) { # etc
You should *not* define "print" methods for S4 classes;
rather you should define "show" methods.
RossB> The file promptClass creates has no methods in it.
>> showMethods(classes="mspathCoefficients")
RossB> Function: initialize (package methods)
RossB> .Object="mspathCoefficients" (inherited from:
RossB> .Object="ANY")
so it's just inherited from "ANY"
RossB> Function: print (package base)
RossB> x="mspathCoefficients"
that's the one
RossB> Function: show (package methods)
RossB> object="mspathCoefficients"
RossB> (inherited from: object="ANY")
so it's just inherited from "ANY"
Ross, it would really be more polite to your readers if you
followed the posting guide and posted complete
fully-reproducible code...
>> getGeneric("print")
RossB> standardGeneric for "print" defined from package
RossB> "base"
RossB> function (x, ...) standardGeneric("print")
RossB> Methods may be defined for
RossB> arguments: x
RossB> I've looked through the code for promptClass, but
RossB> nothing popped out at me.
RossB> It may be relevant that I'm running under ESS in
RossB> emacs. However, I get the same results running R
RossB> from the command line.
RossB> Can anyone tell me what's going on here? This is
RossB> with R 2.4, and I'm not currently using any namespace
RossB> for my definitions.
[and not a package either?]
I'm very willing to look at this, once
you've provided what the posting guide asks for, see above.
Regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about boot ?
> "Dirk" == Dirk Eddelbuettel <[EMAIL PROTECTED]> > on Thu, 30 Nov 2006 08:06:46 -0600 writes: [.] Dirk> The boot package loads fine, and is current. Why does Dirk> R CMD check think it is an error that boot happens to Dirk> live in a particular directory, for as long as that Dirk> directory is known to .libPaths() ? There's quite a difference between .libPaths() in interactive and in "R CMD check" use : 'R CMD check' does not use your R_ENVIRON where you probably set your R_LIBS . I vaguely remember that there a good reasons for this behavior, but I don't recall them at the moment. My solution (or "workaround the design bug"?) has been - for packages I develop - to have small helper scripts that basically do R_LIBS= R CMD check Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Non central chi squared bug (PR#9406)
Full_Name: Alan Bain
Version: 2.4.0
OS: XP
Submission from: (NULL) (155.140.122.227)
Code for pnchisq contains following
if (tSml) {
if (x> f+ theta+ 5*sqrt(2*(f+2*theta) ))){
return 1.; /* better than 0 --- but definately FIXME */
}
}
This needs to check which tail has been requested; it is only correct if the
default lower_tail=1 has been requested; for upper tail should return 0 if more
than 5 std devs away from mean under these circumstances.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non central chi squared bug (PR#9406)
On 12/1/2006 5:44 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Alan Bain
> Version: 2.4.0
> OS: XP
> Submission from: (NULL) (155.140.122.227)
>
>
>
> Code for pnchisq contains following
>
> if (tSml) {
>
> if (x> f+ theta+ 5*sqrt(2*(f+2*theta) ))){
> return 1.; /* better than 0 --- but definately FIXME */
> }
>
> }
>
> This needs to check which tail has been requested; it is only correct if the
> default lower_tail=1 has been requested; for upper tail should return 0 if
> more
> than 5 std devs away from mean under these circumstances.
Could you post a test case to demonstrate this? I don't see it:
> pchisq(1000, 2, 1, FALSE)
[1] 1.720202e-205
> pchisq(1, 2, 1, FALSE)
[1] 0
> pchisq(10, 2, 1, FALSE)
[1] 0
> pchisq(100, 2, 1, FALSE)
[1] 0
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about boot ?
On Fri, 1 Dec 2006, Martin Maechler wrote: >> "Dirk" == Dirk Eddelbuettel <[EMAIL PROTECTED]> >> on Thu, 30 Nov 2006 08:06:46 -0600 writes: > > [.] > >Dirk> The boot package loads fine, and is current. Why does >Dirk> R CMD check think it is an error that boot happens to >Dirk> live in a particular directory, for as long as that >Dirk> directory is known to .libPaths() ? > > There's quite a difference between > .libPaths() in interactive and in "R CMD check" use : > > 'R CMD check' does not use your R_ENVIRON where you probably set > your R_LIBS . That's not the issue here. Even if R_LIBS is set, R CMD check looks for the copies of the standard and recommended packages in .Library (specifically .check_Rd_xrefs does): that is a safety measure as those are the ones against which the checks should be done even if you have development versions elsewhere in R_LIBS. (Not my design, but one that seems highly defensible.) There is no provision in the R scripts to install the recommended packages elsewhere than .Library, but I believe Dirk has a post-install script that breaks the assumptions so this is a Debian-packaging-specific issue. > I vaguely remember that there a good reasons for this behavior, > but I don't recall them at the moment. R CMD does not make use of ~/.Renviron nor R_HOME/etc/Renviron.site: it is like R --vanilla, which is what is used for a lot of batch testing code. -- 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] R 2.4.1 scheduled for December 18
The R Core Team has decided to aim for the release of 2.4.1 on Monday December 18. This involves a feature freeze on Monday the 4th and code freeze on Monday 11th. Automated builds of beta release and release candidate tarballs will be available from the 5th and the 12th, respectively. It is not expected that many changes will occur relative to the current R-patched version, but as always: ---> Bugs reported before the release have a better chance of getting fixed soon. <--- For this reason, and because of the risk of accidentally putting "infelicities" into the final release, please do try out the prereleases. Particularly so if your setup is not mainstream OS-wise or configuration-wise. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning about boot ?
( I added Kurt + Uwe back here again, they had replied earlier in the thread.)
On 1 December 2006 at 11:27, Prof Brian Ripley wrote:
| On Fri, 1 Dec 2006, Martin Maechler wrote:
|
| >> "Dirk" == Dirk Eddelbuettel <[EMAIL PROTECTED]>
| >> on Thu, 30 Nov 2006 08:06:46 -0600 writes:
| >
| > [.]
| >
| >Dirk> The boot package loads fine, and is current. Why does
| >Dirk> R CMD check think it is an error that boot happens to
| >Dirk> live in a particular directory, for as long as that
| >Dirk> directory is known to .libPaths() ?
| >
| > There's quite a difference between
| > .libPaths() in interactive and in "R CMD check" use :
| >
| > 'R CMD check' does not use your R_ENVIRON where you probably set
| > your R_LIBS .
|
| That's not the issue here. Even if R_LIBS is set, R CMD check looks for
| the copies of the standard and recommended packages in .Library
| (specifically .check_Rd_xrefs does): that is a safety measure as those are
| the ones against which the checks should be done even if you have
| development versions elsewhere in R_LIBS. (Not my design, but one that
| seems highly defensible.)
Recall that on Debian (and hence Ubuntu etc), and based on a suggestion by
KH+FL made during DSC2003, we set R_LIBS in the _global_ Renviron file:
[EMAIL PROTECTED]:~> grep R_LIBS /usr/lib/R/etc/Renviron
R_LIBS=${R_LIBS-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
So Martin's point about a 'your R_LIBS' does not really hold. It's not via
~/.Renviron that this is governed.
Moreover, I have for several years now configured R itself (aka "r-base-core"
in Debian package space) to build --without-recommended-packages so if we put
the two together then a) R knows it cannot assume recommended packages, and
b) every function call using .libPaths() always saw the three values set in
R_LIBS --- which is why on the particular setup I use at work,
/usr/local/lib/R/site-library holds "everything", incl rec'd pkgs
/usr/lib/R/site-library is empty, no r-cran-* packages here
/usr/lib/R/library has what r-base-core installs
but no recommended pkgs either
This has the advantage that the 'littler' shell wrapper update.r will update
everything (in /usr/local/lib/R/site-library) with one simple call; apt-get
and Debian take care of /usr/lib/R/library, and there is no overlap between
R's update.packages() and Debian. It's more radical than what I tried
before, but it works *great*.
Apart from the R CMD check whine. I think I should patch that, but I'd need a
hint to where I should start looking.
Or else I have to cave in and put the recommended packages back into
/usr/lib/R/library --- and violate in spirit the implicit contract of leaving
/usr et al to the package management system, and /usr/local to the user. I
don't like breaking that contract.
| There is no provision in the R scripts to install the recommended
| packages elsewhere than .Library, but I believe Dirk has a post-install
| script that breaks the assumptions so this is a Debian-packaging-specific
| issue.
Nothing post-install. For normal Debian packages, we have
r-base-core
+ recommended pkgs using /usr/lib/R/library
r-cran-* from Debianusing /usr/lib/R/site-library
R/user installed pkgs using /usr/local/lib/R/site-library
where the last one is the default by virtue of its first place in R_LIBS.
| > I vaguely remember that there a good reasons for this behavior,
| > but I don't recall them at the moment.
|
| R CMD does not make use of ~/.Renviron nor R_HOME/etc/Renviron.site:
| it is like R --vanilla, which is what is used for a lot of batch testing
| code.
Right, but I had used R_HOME/etc/Renviron, not $R_HOME/etc/Renviron.site
(though arguably "Renviron.site in spirit").
Sorry for the long post, but this question of how to "best" manage R and
Debian packages on Debian/Ubuntu also pops up frequently on the r-sig-debian
list (or, as seen this week, in Doug and my mail box, even from a formerly
prominent CRAN author).
Comments highly welcome!
Cheers from snowy Chicago, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Magic Menu library loading error (PR#9405)
I'd like to add that the most common mistake is to upgrade to IntelMac and forget to delete old plugins that were PowerPC-only or don't work with your new system. Remember - Mac OS X upgrade will keep all your settings and files intact regardless whether they work on your new machine or not. Cheers, Simon On Nov 30, 2006, at 7:43 PM, stefano iacus wrote: > Jeff, > this is not a bug report for R, and you already posted to R-Sig-mac > (and get answered) > Maybe you want to contact the author of MagicMenu (or what ever is > the software you use) to understand why such bad interaction with > R.app takes place. > stefano > > > On 01/dic/06, at 05:51, [EMAIL PROTECTED] wrote: > >> Full_Name: Jeff Lee >> Version: 2.4.0 >> OS: Mac OS X 10.4 (Tiger) >> Submission from: (NULL) (12.150.164.100) >> >> >> Just upgraded to an Intel based Mac. Upon launch, I receive the >> following >> error: >> >> 2006-11-30 12:39:36.870 R[407] *** -[NSBundle load]: Error loading >> code >> /Library/InputManagers/MagicMenuEnabler/MagicMenuEnabler.bundle/ >> Contents/MacOS/MagicMenuEnabler >> for bundle /Library/InputManagers/MagicMenuEnabler/ >> MagicMenuEnabler.bundle, >> error code 2 (link edit error code 0, error number 0 ()) >> >> Functioning of the system seems okay, however. >> >> __ >> 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
[Rd] mixed effects model and r-squared
Heya I am fitting linear mixed effects model in R and want to assess the model fit (with Animal number as random factor; repeated measures for Animals): ts.model <- lme(LOG_FOC_MW ~ R_DN_SUM + ANIMAL + SEX+ YY, data = t.data, random = ~ 1 | ANIMAL, correlation=corCAR1(0.2, form = ~1 | ANIMAL ), method='ML', na.action=na.omit)). Is there a possability to easly compute an R-square from the output of the model summary? I would appreciate any hint. Best regards Lukas °°° Lukas Indermaur, PhD student eawag / Swiss Federal Institute of Aquatic Science and Technology ECO - Department of Aquatic Ecology Überlandstrasse 133 CH-8600 Dübendorf Switzerland Phone: +41 (0) 71 220 38 25 Fax: +41 (0) 44 823 53 15 Email: [EMAIL PROTECTED] www.lukasindermaur.ch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DebtFree Immediately
Select legal counsel just found a mistake in the bank laws. Using waht we found we were successfu1 at entirely eliminating peop1es creditcarddebt with out them having to pay one more dime. We know that our firm can do this for you also. Please contact us- 1-313-263-2706 But why didn't you tell us at first? she asked. The Cannibal Island Doubtless the adventures of the day had tired Rob, for he slept throughout the night as comfortably as if he had been within his own room, lying upon his own bed __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] promptClass misses methods
On Fri, Dec 01, 2006 at 11:37:46AM +0100, Martin Maechler wrote:
> > "RossB" == Ross Boylan <[EMAIL PROTECTED]>
> > on Thu, 30 Nov 2006 22:29:06 -0800 writes:
>
> RossB> I've had repeated problems with promptClass missing
> RossB> methods, usually telling me a class has no methods
> RossB> when it does.
>
> RossB> In my current case, I've defined an S4 class
> RossB> "mspathCoefficients" with a print method
> RossB> setMethod("print", signature(x="mspathCoefficients"),
> RossB> function(x, ...) { # etc
>
> You should *not* define "print" methods for S4 classes;
> rather you should define "show" methods.
Is that because print is used by the S3 system? And is the general
rule to avoid using S3 methods for S4 classes? For example,
http://www.omegahat.org/RSMethods/Intro.pdf, which is referenced in
the package help for methods, discusses show, print and plot as 3
alternatives in S4 (p. 9, though a footnote says that at that
time--2001--R didn't recognize formal methods for printing objects.)
I've been unable to locate much information about combining S3 and S4
methods, though I recall seeing a note saying this issue was still to
be addressed in R. Perhaps it has been now, with setOldClass? At any
rate, the help for that method addresses classes rather than methods,
and I didn't see anything in ?Methods, ?setMethod, or ?setGeneric.
show() raises two additional issues for me. First, it takes a single
argument, and I want to be able to pass in additional arguments via
... . Second, I read some advice somewhere, that I no longer can find,
that show methods should return an object and that object in turn
should be the thing that is printed. I don't understand the
motivation for that rule, at least in this case, because my object is
already a results object.
>
> RossB> The file promptClass creates has no methods in it.
> >> showMethods(classes="mspathCoefficients")
> RossB> Function: initialize (package methods)
> RossB> .Object="mspathCoefficients" (inherited from:
> RossB> .Object="ANY")
>
> so it's just inherited from "ANY"
>
> RossB> Function: print (package base)
> RossB> x="mspathCoefficients"
>
> that's the one
So why isn't promptClass picking it up?
>
> RossB> Function: show (package methods)
> RossB> object="mspathCoefficients"
> RossB> (inherited from: object="ANY")
> so it's just inherited from "ANY"
>
> Ross, it would really be more polite to your readers if you
> followed the posting guide and posted complete
> fully-reproducible code...
I thought it might be overkill in this case. At any rate, it sounds
as if I may be trying to do the wrong thing, so I'd appreciate
guidance on what the right thing to do is.
Here's a toy example:
setClass("A", representation(x="numeric"))
setMethod("print", signature(x="A"), function(x, ...) print([EMAIL PROTECTED],
...) )
promptClass("A")
The generated file has no print method.
>
> >> getGeneric("print")
> RossB> standardGeneric for "print" defined from package
> RossB> "base"
>
> RossB> function (x, ...) standardGeneric("print")
> RossB> Methods may be defined for
> RossB> arguments: x
>
>
> RossB> I've looked through the code for promptClass, but
> RossB> nothing popped out at me.
>
> RossB> It may be relevant that I'm running under ESS in
> RossB> emacs. However, I get the same results running R
> RossB> from the command line.
>
> RossB> Can anyone tell me what's going on here? This is
> RossB> with R 2.4, and I'm not currently using any namespace
> RossB> for my definitions.
>
> [and not a package either?]
The code is part of a package, but I'm developing code snippets in
ESS without loading the whole package.
>
> I'm very willing to look at this, once
> you've provided what the posting guide asks for, see above.
>
> Regards,
> Martin
Thank you. For completeness, here's some system info:
> sessionInfo()
R version 2.4.0 (2006-10-03)
i486-pc-linux-gnu
locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
The Debian package is r-base-core 2.4.0.20061103-1.
Ross
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] printing coefficients with text
On Fri, Dec 01, 2006 at 10:34:45AM +0100, Martin Maechler wrote: > > "RossB" == Ross Boylan <[EMAIL PROTECTED]> > > on Thu, 30 Nov 2006 12:17:55 -0800 writes: > > RossB> I want to print the coefficient estimates of a model > RossB> in a way as consistent with other output in R as > RossB> possible. stats provides the printCoefmat function > RossB> for doing this, but there is one problem. I have an > RossB> additional piece of textual information I want to put > RossB> on the line with the other info on each coefficient. > > that's not a real problem, see below > > RossB> The documentation for printCoefmat says the first > RossB> argument must be numeric, which seems to rule this out. > > it does say that (it says "x: a numeric matrix like object" > which includes data frames with factors) > but you are right that it does preclude a column of "character". Having gone through the code, it's clear the code itself requires all numerics. > > RossB> I just realized I might be able to cheat by inserting > RossB> the text into the name of the variable (fortunately > RossB> there is just one item of text). I think that's in > RossB> the names of the matrix given as the first argument > RossB> to the function. > > yes; it's the rownames(); > i.e., you'd do something like > rownames(myx) <- paste(rownames(myx), format(mytext_var))) > > which seems simple enough to me, > but it only works when the "text" is the first column This actually worked out great for me. > > RossB> Are there any better solutions? Obviously I could > RossB> just copy the method and modify it, but that creates > RossB> duplicate code and loses the ability to track future > RossB> changes to printCoefmat. > > As original author of printCoefmat(), I'm quite willing to > accept and incorporate a patch to the current function > definition (in https://svn.r-project.org/R/trunk/src/library/R/anova.R), > if it's well written. > > As a matter of fact, I think already see how to generalize printCoefmat() > to work for the case of data frame with character columns Yes, that seems as if it would be a good generalization. However, there is code that makes inferences based on the number of columns of data, and I'm not sure how that should work. Probably it should ignore the non-numeric data. > [I would not want a character matrix however; since that would mean > going numeric -> character -> numeric -> formatting (i.e character) > for the 'coefficients' themselves]. > > Can you send me a reproducible example? You mean of an input data frame? Or something else? The input isn't currently a data frame, but I could certainly make one. Do you think generalizing to other types (factor, logical) would make sense too? > or at least an *.Rda file of a save()d such data frame? > > RossB> Thanks. Ross Boylan > > You're welcome, > Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
