[Rd] axTicks on a reverse ylog plot (PR#7973)
There is still issues with the reversed y-log scale plot:
# Test case A: works as expected
plot(10:100,log="y",ylim=c(100,11))
grid()
par("yaxp")
# Test case B: grid does not have horizontal lines; par("yaxp") is
different
plot(1:100,log="y",ylim=c(100,10))
grid()
par("yaxp")
In the second test case, axTicks for the horizontal lines (in grid())
returns numeric(0) for spacing ... how do the tick marks get drawn in
the first place??
-mt
--please do not edit the information below--
Version:
platform = powerpc-apple-darwin8.1.0
arch = powerpc
os = darwin8.1.0
system = powerpc, darwin8.1.0
status = Patched
major = 2
minor = 1.1
year = 2005
month = 06
day = 26
language = R
Locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads,
package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] boxplot by factor (Package base version 2.1.1) (PR#7976)
I consider this to be an old bug, which also persists in Splus 7. It
is unnecessary, and annoying.
## Section 1: Consider a simple data frame with three possible
factors (in levels)
d <- data.frame(a=sort(rnorm(10)*10), b=factor(c(rep("A",4), rep("C",
6)), levels=c("A","B","C")))
tapply(d$a, d$b, mean) # returns three results, which I would expect
plot(a ~ b, d) # plots only two of three objects, ignoring that there
was "C" in the second position
# if I tried to plot a blank in between the two boxplots:
plot(a ~ b, d, at=1:3) # nope: error
plot(a ~ b, d, at=c(1,3)) # nope: out of range (also xlim does
nothing for the formula boxplot method)
# to make this work with the current R/Splus implementation, I have
to add a zero:
d <- rbind(d, data.frame(a=0,b="B")) # which I don't want to do,
since there are no "B"
plot(a ~ b, d) # yuk!
## Section 2: Why is this important? Consider another realistic
example of [synthetic] daily temperature
temp <- 5 - 10*cos(1:365*2*pi/365) + rnorm(365)*3
d1 <- data.frame(year=2005, jday=1:365, date=NA, month=NA, temp) #
jday is Julian day [1,365]
d1$date <- as.Date(paste(d1$year, d1$jday), "%Y %j")
d1$month <- factor(months(d1$date,TRUE), levels=month.abb)
plot(temp ~ month, d1) # perfect, in a perfect meteorological world
d2 <- d1[!d1$month %in% c("Mar","Apr","May","Sep"),] # now let's
remove some data
tapply(d2$temp,d2$month,mean) # perfect
plot(temp ~ month, d2) # ugly, not 12 months, etc. (despite having 12
levels)
# again the only cure is to add zeros to the missing months
(unnecessary forgery of data)
d3 <- d2
for (i in c("Mar","Apr","May","Sep")) {
d3 <- rbind(d3,NA)
d3$month[nrow(d3)] <- i
d3$temp[nrow(d3)] <- 0
}
plot(temp ~ month, d3) # still ugly, but at least has 12 months!
## Section 3: Solution
The obvious solution is to leave a blank where a boxplot should go,
similar to tapply. This would have 1:n positions, where n is the
number of levels of the factor, not the number of factors that have
one or more numbers. The position should also have a label under the
tick mark.
I don't see any reason why the missing data should be completely
ignored. Users wishing to not plot the blanks where the data could go
can simply type (for back-compatibility):
d2$month <- factor(d2$month) # from 12 to 8 levels
Which will produce the same 8-factor plot as above.
## Section 4: Conclusion
I consider this to be a bug in regards to data representation, and
this function is not consistant with other functions like `tapply'.
Considering that the back-compatibility solution is very simple, and
most users would probably prefer a result including all levels (NULL
or real values in each), I feel this an appropriate improvement (and
easy to fix in the code). At the very least, include an option to
honour the factor levels.
Thanks.
-mt
--please do not edit the information below--
Version:
platform = powerpc-apple-darwin8.1.0
arch = powerpc
os = darwin8.1.0
system = powerpc, darwin8.1.0
status = Patched
major = 2
minor = 1.1
year = 2005
month = 06
day = 26
language = R
Locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads,
package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] coplot using Date object (PR#8147)
Full_Name: Michael Toews Version: 2.1.1 OS: WinXP (SP2) Submission from: (NULL) (142.58.206.114) This is a simple feature request concerning the display of the axis in the coplot function. Consider an arbritrary set of values from 1990-1999: date <- as.Date(paste(rep(1990:1999,each=365),1:365),"%Y %j") mon <- factor(months(date,T),levels=month.abb) value <- runif(3650) # Now create coplot for each month: coplot(value ~ date | mon) # The resulting date on the x-axis is not like the axis produced from: plot(value ~ date) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows EPS format error (PR#9518)
This bug can be reproduced using R version 2.4.1 for Windows, where
WinAnsiEncoding is used.
To reproduce this bug, start a Windows R session, and run:
postscript("first.eps", width=6, height=6, horizontal=FALSE,
onefile=FALSE, paper="special")
plot(1:5)
dev.off()
q("no")
Now, start a new R session, and run:
pdf("second.pdf")
plot(1:5)
dev.off()
postscript("third.eps", width=6, height=6, horizontal=FALSE,
onefile=FALSE, paper="special")
plot(1:5)
dev.off()
q("no")
The differences between "first.eps" and "third.eps" are shown to be:
$ diff first.eps third.eps
40d39
< /WinAnsiEncoding [
73d71
< ]
The file "third.eps" is an invalid format, and Vhostview reports:
Error: /undefined in WinAnsiEncoding
Operand stack:
.notdef .notdef .notdef
... etc ...
I've also tested for this peculiar behavior with R 2.4.1 for Debian,
however it checked clean.
+mt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Feature request for 'sprintf' optimization (PR#9621)
Full_Name: Michael Toews
Version: R-devel and 2.4.1
OS: Debian etch and WindowsXP
Submission from: (NULL) (142.58.206.114)
This is a quick demonstration of the present time limitation of 'sprintf' on
long vectors with a suggestion for significant optimization.
First, consider a data.frame with numeric (double) values:
dat <- data.frame(year=as.numeric(rep(1970:2000,each=365)),
yday=as.numeric(1:365))
nrow(dat)
Consider using 'sprintf' in R with and without casting the arrays:
wocast <- system.time(with(dat,sprintf("%04i-%03i",year,yday)))
wcast <- system.time(with(dat,sprintf("%04i-%03i",as.integer(year),
as.integer(yday
100*wocast/wcast # as a percent comparison
My results on a Debian VM with R-devel (r41236) have elapsed ratios of 63408%,
and on Windows XP with R 2.4.1 of 23300%. Using a similar data frame to 'dat'
except, much longer (using 1900:2100 for year; nrow=73365) result in ratios of
120775%. Certainly, the time of the 'sprintf' wrapper is dependent not only on
processor and platform, but more significantly on the data types of the '...'
values passed to the wrapper.
The first and simplest suggestion is to document in 'sprnitf' that it is
significantly faster when supplied with values in the intended data type for
'fmt' through casting (namely using 'as.integer'). However, to the user it would
seem that they have to specify the format twice (e.g., once for '%i' and the
second for 'as.integer()').
A second and more elegant suggestion is for 'sprintf' (or called C code) is to
parse 'fmt' for the data types, and cast the values from '...' according to
those types before continuing with the wrapper call.
(I have not looked at the source code, nor am I good C programmer, so I can't do
more than suggest -- it is possible there could be an alternate optimizations in
the wrapper, since the processing time is very dependent on the length of the
'...' vectors, and it might be evaluating the values repeatedly in a 'for'
loop.)
Thanks!
+mt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] editing pasted text from parameter list through rcompletion crashes R in Windows (PR#9775)
Full_Name: Michael Toews
Version: R 2.5.1
OS: WinXP; SP2
Submission from: (NULL) (142.58.206.114)
To reproduce this crash:
1. Start a new R session normally in Windows
2. Type (an example command): "boxplot(" without pressing enter
3. Copy this text: "c(1,2,6,4,7,3)"
4. Bring Rgui.exe back in focus, and hit "Tab" twice to activate the parameter
list (you should see "x= ...=range= width=" etc.)
4. Paste the text, then press the backspace key, *crash*
There several other variations to crash R similarly, such as pressing the
left-key to edit the pasted text while rcompletion is showing the parameter
list. Present behaviour for rcompletion is to remove the parameter list from the
console after typing has started; however, this list is not removed if text is
pasted, which appears to crash R if the cursor moves backwards (buffer
problems?).
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 5.1
year = 2007
month = 06
day = 27
svn rev = 42083
language = R
version.string = R version 2.5.1 (2007-06-27)
Windows XP (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] End of whiskers of boxplots are repeated on PDF device (PR#10499)
Full_Name: Michael Toews
Version: 2.61
OS: WinXP SP2
Submission from: (NULL) (142.58.206.114)
Using boxplot on a PDF device with more than one group (or boxes) produces
multiple (and overlain) 1st and 3rd quartile ticks. There are exactly the
multiple of boxplot groups as there are of each 1st and 3rd quartile ticks for
each boxplot (drawn as a horizontal line at the end of each boxplot), which is
(groups^2)x2 tick marks in total drawn for the device region.
For example, a device with 4 boxplots:
dat <- data.frame(f=factor(rep(1:4, 10)), x=rnorm(40))
pdf("test.pdf")
plot(dat)
dev.off()
Since the ticks are overlain, the problem is not apparent when viewed in a PDF
reader, but if one were to open the PDF in either CorelDraw or Adobe
Illustrator[*], it is clear that there are 4 ticks for the 1st and 3rd quartile
marks. This example produces (4^2)x32=64 marks, which is 58 too many. In other
examples that use 86 boxplots, there are (86^2)x2=14792 ticks, of which only
2x86 are needed, the rest are redundant.
[*] I'm not familiar with any OSS capable of editing PDFs, however you can see
the tick marks in the PDF file through any text editor on lines 54-61, 77-84,
100-107, and 123-130. The tick marks alternate from 1st to 3rd each of the four
times, so deleting the bottom 6 lines in each group removes the redundancy.
I have also tested the example using the postscript device, but it seems fine
(the skeleton of the boxplots appear to be compound paths, so are drawn very
differently from a low-level graphics standpoint).
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 6.1
year = 2007
month = 11
day = 26
svn rev = 43537
language = R
version.string = R version 2.6.1 (2007-11-26)
Windows XP (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Using unicode with sprintf or paste in Windows (PR#11515)
Full_Name: Michael Toews
Version: 2.7.0
OS: Windows XP SP2
Submission from: (NULL) (24.80.163.230)
Using Unicode characters in Windows works with static strings (as of R 2.7.0),
however fails when used with sprintf() or paste(). For example, on R 2.7.0 for
Windows XP (SP2):
Static string (works, showing Greek Delta character):
> print("\u0394Q = 2.2 L/s")
[1] "ΔQ = 2.2 L/s"
However, when I use paste() or sprintf(), the Unicodeness is lost:
> paste("\u0394Q =",round(1.2345,3),"L/s")
[1] "Q = 1.234 L/s"
> sprintf("\u0394Q = %.3f L/s",1.2345)
[1] "Q = 1.234 L/s"
I have also tested this with R 2.7.0 for Linux, which yields the following:
> print("\u0394Q = 2.2 L/s")
[1] "ΔQ = 2.2 L/s"
> paste("\u0394Q =",round(1.2345,3),"L/s")
[1] "ΔQ = 1.234 L/s"
> sprintf("\u0394Q = %.3f L/s",1.2345)
[1] "ΔQ = 1.234 L/s"
(Note: this was posted on R-help with no replies:
https://stat.ethz.ch/pipermail/r-help/2008-May/162815.html )
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Double HTML encoding in R Bug Tracking Submission form (PR#11517)
The "New Bug Report" form available from http://bugs.r-project.org/ appears to double encode the HTML of the "body" text area of the form. This behaviour can be seen in submission ID # 11515, where (as an example) "Î" is converted to "Δ" in the browser view or "Δ" in the HTML source code. Conversion to "Δ" in the HTML source is sufficient to render "Î" in the browser output. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug with message if there is no documentation; R2.8alpha Win32 (PR#13131)
In the latest R 2.8 alpha for Win32, if either of the commands are typed:
> help("erfc")
.. or ..
> ?erfc
the result is:
No documentation for 'erfc' in specified packages and libraries:
you could try '??erfc'
This should be: 'help.search("erfc")', as shown in R 2.7.2
Apologies if this has already been submitted/fixed.
-Mike
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status = alpha
major = 2
minor = 8.0
year = 2008
month = 10
day = 03
svn rev = 46594
language = R
version.string = R version 2.8.0 alpha (2008-10-03 r46594)
Windows XP (build 2600) Service Pack 3
Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.table does not quote col.names properly (PR#9044)
Full_Name: Michael Toews
Version: 2.3.1
OS: Mac OS 10.4.6 and WinXP/SP2
Submission from: (NULL) (24.80.163.133)
This bug also affects related functions (write.csv, etc.), and can be
demonstrated using either a matrix or data frame:
m <- matrix(1:9,nrow=3,
dimnames=list(c("A","B","C"),
c("I","II","III")))
write.table(m)
write.table(m,col.names=FALSE)
write.table(m,row.names=FALSE)
Note that the last 'write.table' call has unquoted column headers. A suggested
fix for this problem is:
Index: write.table.R
===
--- write.table.R (revision 38447)
+++ write.table.R (working copy)
@@ -86,9 +86,8 @@
if(!is.null(col.names)) {
if(append)
warning("appending column names to file")
- if(length(quote))
- col.names <- paste("\"", gsub('"', qstring, col.names),
- "\"", sep = "")
+ col.names <- paste("\"", gsub('"', qstring, col.names),
+ "\"", sep = "")
writeLines(paste(col.names, collapse = sep), file, sep = eol)
}
However, it is unknown why the "if(length(quote))" is used in the original code
(please check before a commit). The length of quote will be 0 here, since the
matrix has all numbers.
This bug does not occur with a data frame with mixed number and factor/character
columns.
+mt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rgui.exe plot device "Save as" crash (PR#9237)
Full_Name: Michael Toews Version: 2.3.1 OS: WindowsXP Home/Proffesional SP2 Submission from: (NULL) (142.58.206.114) Hi, I have a bug that I can reproduce on two different MS Windows platforms (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the "Save as" dialog when saving a plot from a Windows device onto the Desktop. This bug is difficult to reproduce, but here are some instructions to attempt a crash: 1) Start R from Start menu 2) Plot something simple, such as "plot(1:5)" 3) Choose "File > Save as PDF" 4) In the dialog, click the "Save in:" drop-down menu at the top, and select "Desktop" 5) Type "boohoo" in the "File name:" field, and click "Save" 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or window controls, except for "boohoo.pdf" (although this isn't always the case). If you don't crash, repeat steps 3 to 5 again until a crash. 7) *crash*; Windows will display the default crash dialog; Rgui.exe will appear in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of CPU. 8) Click "Don't Send" from the dialog 9) Observe that "Rgui.exe" is now using all available CPU resources for that thread (this is about 50 for Hyper-threading-enabled or dual-core CPUs). It is probably in an infinite loop. 10) Choose "Rgui.exe" from the Processes in Windows Task Manager, and click "End Process". Now your system will be stable, and you can repeat the bug, if you wish. Here are some things that do _not_ affect the outcome: - Presence or absence of a custom .Rprofile in C:\Program Files\R\R-2.3.1, or Rconsole in "My Documents" - The use of a different file name in step 5; I have also tried "tmp" and "rat a tat tat", so spaces don't seem to matter - The complexity of the plot - Active or inactive Windows devices - MDI or SDI modes for GUI Here are some things that _do_ affect the outcome: - No crash if you "Save as" any of the Jpeg options, but crash for all of the other formats (Metafile, Postscript, etc.) - No crash if in other folder, such as "My Documents"; this crash seems to happen only in the Desktop folder when accessed through the drop-down list at the top or the button on the left-hand side (oddly enough, when navigating an absolute path from C:\Documents and Settings\etc..\Desktop, there is no crash) - In the "Save as" dialog, if you navigate to the Desktop folder by selecting the button on the left-hand side of the dialog (rather than in the "Save in:" drop-down field as indicated in step 4), the crash does _not_ trigger the default Microsoft crash dialog, and Rgui.exe silently crashes (disappears), but remains as an active process, using ~ 50% of CPU resources, and requires a manual "End Process". - If "Debug" (if available) or "Send Report [to Microsoft]" are pressed in the crash dialog, the Rgui.exe process ends normally, and no manual "End Process" is required. Sorry if this seems "TooMuchAtOnce", but it is all the same bug with lots of details. My guess is it has something to do with the Tooltip from the Windows system "Save as" dialog, which suggests there is a bug in R's implementation of the system "Save as" dialog. As well, it appears to have problems with the "Desktop" folder when navigated from the convenient "Desktop" links (either from the upper drop-down list or left-hand button) in the "Save" dialog. I don't have access to a pre-compiled Win32 EXE of the the R 2.4.0 alpha releases, otherwise I would try to trigger this bug on the upcoming release. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui.exe plot device "Save as" crash (PR#9237)
I was guessing that this bug would be difficult to trace, I just wanted to document its presence. It is not critical, and can be easily be avoided by: - Saving in Jpeg format; or - Not saving to the Desktop (unless navigated from C:\Documents and Settings\etc.) I'm not convinced that this bug is related to Adobe (as mentioned in Followup 1) .. my example uses PDF, but the same bug occurs when using Png, and others (except Jpeg!?). > I really don't know where to go to start looking for this. It would be > nice if we had something like valgrind for Windows, but we don't. Regarding valgrind (or other memory debuggers): I'm not a Windows programmer, but would WinDbg be helpful for debugging this? I tried this (free download from MS), and it shows plenty of debugging info, such as values of registers, and the sequences of assembly operators on the CPU, etc. When I open Rgui.exe, it shows all sorts of modules loading when the "Save as" dialog appears, and when Tooltips are triggered; such as: PDFShell.dll (from Acrobat 7.0), esriShellExt.dll (from ArcGIS), and various *.so files from TortoiseSVN\iconv. The crash occurs, and WinDbg prints: (934.ba8): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=049c2038 ebx= ecx=0486f1d4 edx=0486f1cc esi=0486f3e0 edi=000aa0ec eip=7ca5158e esp=0486f134 ebp=0486f37c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=00010246 *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\SHELL32.dll - SHELL32!SHCreateQueryCancelAutoPlayMoniker+0xf8a8: 7ca5158e 8b08mov ecx,dword ptr [eax] ds:0023:049c2038= and when I press "Go" in WinDbg, the instruction/error repeats ad nauseam (with the 'efl' register flipping between 0246 and 00010246; hence the infinite loop). I didn't load the "symbols file" (I'm not sure what this is -- WinDbg is new territory for me today), but I would guess this could make the debugging output more meaningful. My first impression of WinDbg is that it can be useful for this situation (and others). +mt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
