[Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6776)
Bars are not stacked, but superimposed. This happens even with the first example of barplot: tN - table(Ni - rpois(100, lambda=5)) r - barplot(tN, col='gray') --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 9.0 year = 2004 month = 04 day = 12 language = R Windows XP Professional (build 2600) Service Pack 1.0 Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:utils, Autoloads, package:base ...°})) ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean \ ___ ) \/ECO\ ( Numerical Ecology of Aquatic Systems /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium /NUM\/ ) \___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 \ ) email: [EMAIL PROTECTED] ) ) ) ) ) SciViews project coordinator (http://www.sciviews.org) ( ( ( ( ( ... __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6776)
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED] wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that in
the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead to
the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default color
choice should then be modified as well.
Z
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 1
minor = 9.0
year = 2004
month = 04
day = 12
language = R
Windows XP Professional (build 2600) Service Pack 1.0
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:utils, Autoloads, package:base
...°}))
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
\/ECO\ ( Numerical Ecology of Aquatic Systems
/\___/ ) Mons-Hainaut University, Pentagone
/ ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium
/NUM\/ )
\___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
\ ) email: [EMAIL PROTECTED]
) ) ) ) ) SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (
...
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6777)
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED] wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
=20
tN - table(Ni - rpois(100, lambda=3D5))
r - barplot(tN, col=3D'gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col =3D gray)
is used instead, everything is as it was in 1.8.1. The reason is that in
the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) =3D=3D 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead to
the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default color
choice should then be modified as well.
Z
--please do not edit the information below--
=20
Version:
platform =3D i386-pc-mingw32
arch =3D i386
os =3D mingw32
system =3D i386, mingw32
status =3D
major =3D 1
minor =3D 9.0
year =3D 2004
month =3D 04
day =3D 12
language =3D R
=20
Windows XP Professional (build 2600) Service Pack 1.0
=20
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:utils, Autoloads, package:base
=20
...=B0}))
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
\/ECO\ ( Numerical Ecology of Aquatic Systems
/\___/ ) Mons-Hainaut University, Pentagone
/ ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium
/NUM\/ )
\___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
\ ) email: [EMAIL PROTECTED]
) ) ) ) ) SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (
...
=20
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
=20
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6776)
On Fri, 16 Apr 2004 09:59:02 -0400 Duncan Murdoch wrote:
On Fri, 16 Apr 2004 15:44:52 +0200, Achim Zeileis
[EMAIL PROTECTED] wrote :
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED]
wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that
in the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead
to the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default
color choice should then be modified as well.
I'm pretty sure the problem is due to this change,
Of course, yes. Kurt and I have been working on this and as I recall
used mainly vectors and matrices for testing and obviously not 1-way
tables.
a few lines below the ones you listed:
1.8.1: width - rep(width, length.out = NR * NC)
1.9.0: width - rep(width, length.out = NR)
This change was made at the same time as the offset arg was
introduced; is it intentional?
Yes, we changed it in that way so that the col, width and offset
arguments are expanded (if necessary) in a similar way. Compare for
example
x - cbind(1:3, 2)
barplot(x, width = 1:2, beside = FALSE)
barplot(x, width = 1:2, beside = TRUE)
in 1.8.1 and 1.9.0. In the new version the code tries to find a
(statistically) sensible grouping in both cases. One could argue that in
certain cases the widths of each bar should be controlled and they
should not be grouped...depends on what you want to do if length(width)
does not match the number of bars drawn.
Z
Duncan Murdoch
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] barplot() does not draw bars correctly in R 1.9.0 (PR#6778)
On Fri, 16 Apr 2004 09:59:02 -0400 Duncan Murdoch wrote:
On Fri, 16 Apr 2004 15:44:52 +0200, Achim Zeileis
[EMAIL PROTECTED] wrote :
On Fri, 16 Apr 2004 11:40:46 +0200 (CEST) [EMAIL PROTECTED]
wrote:
Bars are not stacked, but superimposed. This happens even with the
first example of barplot:
tN - table(Ni - rpois(100, lambda=5))
r - barplot(tN, col='gray')
AFAICS, this problem occurs exactly for 1-way tables like above. If
barplot(as.vector(tN), col = gray)
is used instead, everything is as it was in 1.8.1. The reason is that
in the new version of barplot.default the following code (which
remained unchanged) does not do anymore what do what one would want:
if (is.vector(height)) {
height - cbind(height)
beside - TRUE
}
else if (is.array(height) (length(dim(height)) == 1)) {
height - rbind(height)
beside - TRUE
}
that is, vectors and 1-way tables are treated differently which lead
to the problem. Using cbind() instead of rbind() in the second half,
overcomes this problem.
However, the colors are then chosen in the same way as for vectors,
resulting in different colors than in R 1.8.1. Maybe the default
color choice should then be modified as well.
I'm pretty sure the problem is due to this change,
Of course, yes. Kurt and I have been working on this and as I recall
used mainly vectors and matrices for testing and obviously not 1-way
tables.
a few lines below the ones you listed:
1.8.1: width - rep(width, length.out = NR * NC)
1.9.0: width - rep(width, length.out = NR)
This change was made at the same time as the offset arg was
introduced; is it intentional?
Yes, we changed it in that way so that the col, width and offset
arguments are expanded (if necessary) in a similar way. Compare for
example
x - cbind(1:3, 2)
barplot(x, width = 1:2, beside = FALSE)
barplot(x, width = 1:2, beside = TRUE)
in 1.8.1 and 1.9.0. In the new version the code tries to find a
(statistically) sensible grouping in both cases. One could argue that in
certain cases the widths of each bar should be controlled and they
should not be grouped...depends on what you want to do if length(width)
does not match the number of bars drawn.
Z
Duncan Murdoch
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] summary() with argument of class difftime (PR#6780)
Full_Name: J. R. M. Hosking Version: 1.9.0 OS: Windows 2000 Submission from: (NULL) (129.34.20.23) dt-as.Date(2002-03-04)-as.Date(2001-02-03) jstr(dt) difftime(units:days)(1) 394 summary(dt) Error in Summary.difftime(..., na.rm = na.rm) : sum not defined for difftime objects When x is of class difftime, either sum(x) should be permitted or summary(x) should not try to compute the mean. (R 1.9.0, Windows binary from CRAN) __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary() with argument of class difftime (PR#6780)
Where does it say that summary() can be applies to difftime objects? On Fri, 16 Apr 2004 [EMAIL PROTECTED] wrote: Full_Name: J. R. M. Hosking Version: 1.9.0 OS: Windows 2000 Submission from: (NULL) (129.34.20.23) dt-as.Date(2002-03-04)-as.Date(2001-02-03) jstr(dt) difftime(units:days)(1) 394 summary(dt) Error in Summary.difftime(..., na.rm = na.rm) : sum not defined for difftime objects When x is of class difftime, either sum(x) should be permitted or summary(x) should not try to compute the mean. (R 1.9.0, Windows binary from CRAN) -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] type.convert (PR#6781)
Full_Name: J. R. M. Hosking Version: 1.9.0 OS: Windows 2000 Submission from: (NULL) (129.34.20.23) Two problems, perhaps related: (1) na.strings is not honored when x is non-numeric and as.is=T type.convert( c(abc,-), as.is=T, na.strings=- ) [1] abc - ... unless x consists only of NAs type.convert( c(abc,-), as.is=T, na.strings=c(-,abc) ) [1] NA NA But with x numeric or as.is FALSE (or omitted), it works as advertised: type.convert( c(abc,-), na.strings=- ) [1] abc NA Levels: abc type.convert( c(6,-), na.strings=- ) [1] 6 NA (2) When na.strings is omitted, blank strings in nonnumeric vectors are not converted into NAs (regardless of the value of as.is). type.convert(c(6,, )) # OK: gives 6 NA NA [1] 6 NA NA type.convert(c(A,, )) # gives a factor with 3 levels and no NAs [1] A Levels:A type.convert(c(A,, ),as.is=T) # gives a char vector with no NAs [1] A Rider: it would be nice if type.convert had a strip.white argument, so that type.convert(c( 6, -),na.strings=-,strip.white=T) would return a numeric vector. Stripping leading and trailing blanks can be time-consuming, and could presumably be done more quickly by an .Internal function such as the one called by type.convert. (R 1.9.0, Windows binary from CRAN) __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows startup menu display problem in 1.9.0 (PR#6783)
Full_Name: Brian J. Smith Version: 1.9.0 OS: WinXp Submission from: (NULL) (129.255.217.48) WinXP; R 1.9.0 running under Rgui.exe. winMenuAdd calls via my .Rprofile file do not seem to work and, instead, result in the following error message after the R GUI starts: Error in eval(expr, envir, enclos) : couldn't find function winMenuAdd Any subsequent calls to winMenuAdd from the R console GUI window work fine. The same Rprofile works fine under R 1.8.1. Bug report #2817 describes a similar problem that occurred with R 1.7.0. Brian __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
