Has there been a recent change in the behavior of binary operators? In SparseM it was, until quite recently ok to do scalar multiplication but now,
> A*4 Error in A * 4 : non-numeric argument to binary operator > 4*A Error in 4 * A : non-numeric argument to binary operator > A%*%A An object of class "matrix.csr" Slot "ra": [1] 1 1 1 Slot "ja": [1] 1 2 3 Slot "ia": [1] 1 2 3 4 Slot "dimension": [1] 3 3 Clearly, I need to now specify that objects (like A) of our sparse matrix classes are numeric, but I am curious about what happened in the interim to have necessitated this, and to evaluate how negligent I was to have missed it. url: www.econ.uiuc.edu/~roger/my.html Roger Koenker email [EMAIL PROTECTED] Department of Economics vox: 217-333-4558 University of Illinois fax: 217-244-6678 Champaign, IL 61820 On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote: > Send R-devel mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of R-devel digest..." > > > Today's Topics: > > 1. var() doesn't work for R-1.8.0 (bin wang) > 2. Re: var() doesn't work for R-1.8.0 (Uwe Ligges) > 3. strptime (PR#4204) ([EMAIL PROTECTED]) > 4. possible bug in diag() (Marsland, John) > 5. Re: possible bug in diag() (Simon Urbanek) > 6. Re: R on BeOS (Simon Urbanek) > 7. dwilcox (PR#4212) ([EMAIL PROTECTED]) > 8. dwilcox (PR#4213) ([EMAIL PROTECTED]) > 9. Re: dwilcox (PR#4212) (Torsten Hothorn) > 10. Re: couldn't find function "setClass" (Kurt Hornik) > 11. Sweave: option family=... (Wolfram Fischer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Sep 2003 09:23:21 -0500 > From: bin wang <[EMAIL PROTECTED]> > Subject: [Rd] var() doesn't work for R-1.8.0 > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I installed R-1.8.0 alpha in my machine, which runs redhat9.0. > > I tried to run > > x <- c(1,2,3,4) > var(x) > > It said 4 parameters are needed and I just provide 3. > > Thanks > > Bin > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Sep 2003 16:55:47 +0200 > From: Uwe Ligges <[EMAIL PROTECTED]> > Subject: Re: [Rd] var() doesn't work for R-1.8.0 > To: bin wang <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii; format=flowed > > bin wang wrote: > > > I installed R-1.8.0 alpha in my machine, which runs redhat9.0. > > I tried to run > > > > x <- c(1,2,3,4) > > var(x) > > > > It said 4 parameters are needed and I just provide 3. > > Thanks > > > > Bin > > > > ______________________________________________ > > [EMAIL PROTECTED] mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > This issue arised earlier this week. Unpack the sources into a clean > directory and try compiling again. > > Uwe Ligges > > > ------------------------------ > > Message: 3 > Date: Wed, 17 Sep 2003 17:13:27 +0200 (MET DST) > From: [EMAIL PROTECTED] > Subject: [Rd] strptime (PR#4204) > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > Full_Name: Peng Liu > Version: 1.7.1 > OS: XP Home > Submission from: (NULL) (128.109.14.2) > > > > strptime(c("80040601"),format="%y%m%d%H") > [1] "1980-04-06 01:00:00" > > strptime(c("80040602"),format="%y%m%d%H") > [1] "1980-04-06 01:00:00" > > Convert incorrectly. > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Sep 2003 17:51:40 +0100 > From: "Marsland, John" <[EMAIL PROTECTED]> > Subject: [Rd] possible bug in diag() > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="iso-8859-1" > > > It concerns trival diagonal matrices: > > > diag(1) > [,1] > [1,] 1 > > > > diag(rnorm(1)) > <0 x 0 matrix> > > > > diag(rnorm(1),nrow=1) > [,1] > [1,] 0.4843697 > > There's an obvious work around... but I thought it was worth notifying the > list. > > Regards, > > John Marsland > > > ********************************************************************** > This is a commercial communication from Commerzbank AG.\ \ T...{{dropped}} > > > ------------------------------ > > Message: 5 > Date: Wed, 17 Sep 2003 20:01:14 +0200 > From: Simon Urbanek <[EMAIL PROTECTED]> > Subject: Re: [Rd] possible bug in diag() > To: "Marsland, John" <[EMAIL PROTECTED]> > Cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Wednesday, September 17, 2003, at 06:51 PM, Marsland, John wrote: > > > It concerns trival diagonal matrices: > > [...] > >> diag(rnorm(1)) > > <0 x 0 matrix> > > > >> diag(rnorm(1),nrow=1) > > [,1] > > [1,] 0.4843697 > > > > There's an obvious work around... but I thought it was worth notifying > > the > > list. > > I fail to see any reason for you posting this here, since this is a > perfectly documented behavior - ?diag says: > > Note: > Using 'diag(x)' can have unexpected effects if 'x' is a vector > that could be of length one. Use 'diag(x, nrow = length(x))' for > consistent behaviour. > > Hence you can safely assume that the "list" needs no notification of > this. > > Cheers, > Simon > > > ------------------------------ > > Message: 6 > Date: Wed, 17 Sep 2003 20:01:34 +0200 > From: Simon Urbanek <[EMAIL PROTECTED]> > Subject: Re: [Rd] R on BeOS > To: "Ole Sieling" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Sunday, September 14, 2003, at 06:01 PM, Ole Sieling wrote: > > > Hello, > > I have compiled R-1.7.1 on Beos R5 (x86) and got it running. > > The modules x11 and internet dont work (so the only working display is > > postscript()). > > The libraries all compile, but there is a problem with methods. > > I get the following error when i make methods: > > > > dumping R code in package 'methods' > > Error in .Call("R_initialize_methods_metadata", table, PACKAGE = > > "methods") : > > .Call function name not in load table > > Execution halted > > This may indicate a problem of missing/superfluous underscores in > exported symbols of shared libraries - see the discussion concerning > OpenBSD port conducted recently (late July; see also > HAVE_NO_SYMBOL_UNDERSCORE). Each platform has different requirements in > that respect and "methods" is the first package that loads a dynamic > library and uses its functions. > > Cheers, > Simon > > > ------------------------------ > > Message: 7 > Date: Thu, 18 Sep 2003 01:20:19 +0200 (MET DST) > From: [EMAIL PROTECTED] > Subject: [Rd] dwilcox (PR#4212) > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > Full_Name: Mark J. Lamias > Version: 1.7.0 > OS: Windows 2000 Pro > Submission from: (NULL) (65.222.84.72) > > > I am running the qwilcox procedure and it is producing incorrect results. For > example, dwilcox(.025, 3, 5) should equal 6, but it is equal to 1. Similarly, > dwilcox(.025, 3, 6) should equal 7, but it equals 2. The critical values are > not set being returned with the correct values. I've verified this with a > program that performs direct enumeration to determine the appropriate critical > values for .05 (two- tail): > > n1 n2 n crtical_value > 3 5 8 6 > 3 6 9 7 > 3 7 10 7 > 3 8 11 8 > 3 9 12 8 > 3 10 13 9 > 3 11 14 9 > 3 12 15 10 > 3 13 16 10 > 3 14 17 11 > 3 15 18 11 > 3 16 19 12 > 3 17 20 12 > 3 18 21 13 > 3 19 22 13 > 3 20 23 14 > 3 21 24 14 > 3 22 25 15 > 3 23 26 15 > 3 24 27 16 > 3 25 28 16 > 3 26 29 17 > 3 27 30 17 > 3 28 31 18 > 3 29 32 19 > 3 30 33 19 > 4 4 8 10 > 4 5 9 11 > 4 6 10 12 > 4 7 11 13 > 4 8 12 14 > 4 9 13 14 > 4 10 14 15 > 4 11 15 16 > 4 12 16 17 > 4 13 17 18 > 4 14 18 19 > 4 15 19 20 > 4 16 20 21 > 4 17 21 21 > 4 18 22 22 > 4 19 23 23 > 4 20 24 24 > 4 21 25 25 > 4 22 26 26 > 4 23 27 27 > 4 24 28 27 > 4 25 29 28 > 4 26 30 29 > 4 27 31 30 > 4 28 32 31 > 4 29 33 32 > 4 30 34 33 > 5 5 10 17 > 5 6 11 18 > 5 7 12 20 > 5 8 13 21 > 5 9 14 22 > > > ------------------------------ > > Message: 8 > Date: Thu, 18 Sep 2003 01:21:06 +0200 (MET DST) > From: [EMAIL PROTECTED] > Subject: [Rd] dwilcox (PR#4213) > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > Full_Name: Mark J. Lamias > Version: 1.7.0 > OS: Windows 2000 Pro > Submission from: (NULL) (65.222.84.72) > > > I am running the qwilcox procedure and it is producing incorrect results. For > example, dwilcox(.025, 3, 5) should equal 6, but it is equal to 1. Similarly, > dwilcox(.025, 3, 6) should equal 7, but it equals 2. The critical values are > not set being returned with the correct values. I've verified this with a > program that performs direct enumeration to determine the appropriate critical > values for .05 (two- tail): > > n1 n2 n crtical_value > 3 5 8 6 > 3 6 9 7 > 3 7 10 7 > 3 8 11 8 > 3 9 12 8 > 3 10 13 9 > 3 11 14 9 > 3 12 15 10 > 3 13 16 10 > 3 14 17 11 > 3 15 18 11 > 3 16 19 12 > 3 17 20 12 > 3 18 21 13 > 3 19 22 13 > 3 20 23 14 > 3 21 24 14 > 3 22 25 15 > 3 23 26 15 > 3 24 27 16 > 3 25 28 16 > 3 26 29 17 > 3 27 30 17 > 3 28 31 18 > 3 29 32 19 > 3 30 33 19 > 4 4 8 10 > 4 5 9 11 > 4 6 10 12 > 4 7 11 13 > 4 8 12 14 > 4 9 13 14 > 4 10 14 15 > 4 11 15 16 > 4 12 16 17 > 4 13 17 18 > 4 14 18 19 > 4 15 19 20 > 4 16 20 21 > 4 17 21 21 > 4 18 22 22 > 4 19 23 23 > 4 20 24 24 > 4 21 25 25 > 4 22 26 26 > 4 23 27 27 > 4 24 28 27 > 4 25 29 28 > 4 26 30 29 > 4 27 31 30 > 4 28 32 31 > 4 29 33 32 > 4 30 34 33 > 5 5 10 17 > 5 6 11 18 > 5 7 12 20 > 5 8 13 21 > 5 9 14 22 > > > ------------------------------ > > Message: 9 > Date: Thu, 18 Sep 2003 09:03:57 +0200 (CEST) > From: Torsten Hothorn <[EMAIL PROTECTED]> > Subject: Re: [Rd] dwilcox (PR#4212) > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > Full_Name: Mark J. Lamias > > Version: 1.7.0 > > OS: Windows 2000 Pro > > Submission from: (NULL) (65.222.84.72) > > > > > > I am running the qwilcox procedure and it is producing incorrect results. For > > example, dwilcox(.025, 3, 5) > > not really: > > R> dwilcox(.025, 3, 5) > [1] 0 > > which is natural since the statistic can take integer values only. > > > should equal 6, but it is equal to 1. Similarly, > > dwilcox(.025, 3, 6) should equal 7, but it equals 2. The critical values are > > not set being returned with the correct values. I've verified this with a > > program that performs direct enumeration to determine the appropriate critical > > values for .05 (two- tail): > > > > n1 n2 n crtical_value > > 3 5 8 6 > > > I think you failed to notice what `?qwilcox' tries to tell you: > > This distribution is obtained as follows. Let 'x' and 'y' be two > random, independent samples of size 'm' and 'n'. Then the Wilcoxon > rank sum statistic is the number of all pairs '(x[i], y[j])' for > which 'y[j]' is not greater than 'x[i]'. This statistic takes > values between '0' and 'm * n', and its mean and variance are 'm * > n / 2' and 'm * n * (m + n + 1) / 12', respectively. > > Moreover, it is documented that `probabilities are P[X <= x]' and > therefore > > R> qwilcox(.025, 3, 5) + 3*4/2 > [1] 7 > > means "the smallest x with P(W <= x) => 0.025 is 7" which you can check > easily > > R> pwilcox(7 - 3*4/2, 3, 5) > [1] 0.03571429 > > whereas following your calculations > > R> pwilcox(6 - 3*4/2, 3, 5) > [1] 0.01785714 > > Best, > > Torsten > > > 3 6 9 7 > > 3 7 10 7 > > 3 8 11 8 > > 3 9 12 8 > > 3 10 13 9 > > 3 11 14 9 > > 3 12 15 10 > > 3 13 16 10 > > 3 14 17 11 > > 3 15 18 11 > > 3 16 19 12 > > 3 17 20 12 > > 3 18 21 13 > > 3 19 22 13 > > 3 20 23 14 > > 3 21 24 14 > > 3 22 25 15 > > 3 23 26 15 > > 3 24 27 16 > > 3 25 28 16 > > 3 26 29 17 > > 3 27 30 17 > > 3 28 31 18 > > 3 29 32 19 > > 3 30 33 19 > > 4 4 8 10 > > 4 5 9 11 > > 4 6 10 12 > > 4 7 11 13 > > 4 8 12 14 > > 4 9 13 14 > > 4 10 14 15 > > 4 11 15 16 > > 4 12 16 17 > > 4 13 17 18 > > 4 14 18 19 > > 4 15 19 20 > > 4 16 20 21 > > 4 17 21 21 > > 4 18 22 22 > > 4 19 23 23 > > 4 20 24 24 > > 4 21 25 25 > > 4 22 26 26 > > 4 23 27 27 > > 4 24 28 27 > > 4 25 29 28 > > 4 26 30 29 > > 4 27 31 30 > > 4 28 32 31 > > 4 29 33 32 > > 4 30 34 33 > > 5 5 10 17 > > 5 6 11 18 > > 5 7 12 20 > > 5 8 13 21 > > 5 9 14 22 > > > > ______________________________________________ > > [EMAIL PROTECTED] mailing list > > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > > > > > ------------------------------ > > Message: 10 > Date: Thu, 18 Sep 2003 10:43:01 +0200 > From: Kurt Hornik <[EMAIL PROTECTED]> > Subject: Re: [Rd] couldn't find function "setClass" > To: Martin Maechler <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > >>>>> Martin Maechler writes: > > >>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> > >>>>> on Wed, 17 Sep 2003 07:05:57 +0100 (BST) writes: > > BDR> On Tue, 16 Sep 2003, John Chambers wrote: > > > <..............> > > > JMC> That (apparently) the problem arises in such a > JMC> special situation is confusing for users. At least > JMC> for me, it's ONLY in the combination of saved image > JMC> and no namespace. > > JMC> That the user does not need a require(methods) when > JMC> testing the code directly but does (sometimes) when > JMC> the source code is in package source is not a > JMC> feature. If we can avoid this complexity, that would > JMC> encourage package developers. > > BDR> Unfortunately, it is not necessarily true that > BDR> require(methods) is not needed when testing: site > BDR> admins or "users" might have changed the default > BDR> packages from the system default. > > JMC> Indeed, but then the user would always see things this > JMC> way. Consistency makes people feel more secure. > > BDR> Otoh, once we use --vanilla for the save image > BDR> creation, it seems that this eliminates all > BDR> (reasonable) possibilities for changing the default > BDR> packages (or am I missing something?). So we could > BDR> use the system default rather than just base here. > > JMC> Intuitively, --vanilla means "the standard flavor", as opposed to > JMC> --stripped, say, so it would seem more natural to have the system > JMC> defaults wherever possible. > > BDR> As I have said before, --vanilla does not change the > BDR> default packages, nor the possibility of setting the > BDR> default packages at system level. > > BDR> gannet% env R_DEFAULT_PACKAGES=ts R --vanilla > > BDR> really does load only "package:ts". > > BDR> From ?Startup > > >>> The command-line flag '--vanilla' implies > >>> '--no-site-file', '--no-init-file', '--no-restore' and > >>> '--no-environ'. > > BDR> and let me add, nothing else. It is possible for > BDR> sysadmins to change the system environment and profile > BDR> files, and some do. > > > Agreed. > > So this means we should do more than just "--vanilla". > > In some cases, we already do set environment variables such as > > LANG=C and so we should also be allowed to set > > R_DEFAULT_PACKAGES to the standard default (rather than the > > local installation one). > > Done now. It turns out that 'R_DEFAULT_PACKAGES=' does the job. > > I also modified R CMD check to use the system default when running the > examples and specific tests (although running with > R_DEFAULT_PACKAGES=NULL seems to work for all CRAN packages). > > -k > > > ------------------------------ > > Message: 11 > Date: Thu, 18 Sep 2003 11:19:38 +0200 > From: Wolfram Fischer <[EMAIL PROTECTED]> > Subject: [Rd] Sweave: option family=... > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > I would propose to add an option ``family'' > to RweaveLatex() resp. RweaveLatexSetup() > in order to be able to set the font family > for postscript and pdf graphics: > > <<fig=TRUE, family=Palatino>>= > ... > @ > > Thanks > > Wolfram Fischer > > > ------------------------------ > > _______________________________________________ > [EMAIL PROTECTED] mailing list DIGESTED > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel > > > End of R-devel Digest, Vol 7, Issue 18 > ************************************** > ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
