Re: [Rd] Double HTML encoding in R Bug Tracking Submission form (PR#11517)
[EMAIL PROTECTED] wrote: 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 Well, the repository handles emails, and the report form sends mail to the bug repository. The report form sends HTML codes without any indication that it is doing so, so the codes get rendered in the browser view. This latter part is actually correct behaviour since the alternative is to mangle all ampersands. So the main bug is that the report form is not mail-encoding the contents if non-ASCII. *However*, even with properly encoded mails, the browser view will not interpret the encoding, which is particularly annoying with quoted-printable (which uses the equal sign as an escape character and changes = to =3D). Also, see what happens with my signature which has a UTF-8 character inside. All in all, the whole mess indicates that the bug repository software is dying. It has long since been abandoned by its original author and it makes no sense for the R Core Team to make major changes to its internals. We've been wanting to move to something more mainstream for quite a while, but it takes some effort to find out how to move all the old pending and resolved reports across. -- 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
[Rd] Listing all possible samples of Size two form Large Population
Respected All, I need some efficient program or package to draw all possible samples of size two without replacement. I am using "combinat" package to list all possible samples but it hangs my computer for larger populations say 10,000 (i.e. 49995000 all possible samples). I wish to even work for larger populations then this and replicate this procedure for many times. Kindly can anyone figure out the possibilities and let me know. Best Regards, Nadeem Shafique Butt __ 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] (PR#11482)
You didn't mention on R-help that the bug was already fixed in 2.7.0 patched, otherwise I wouldn't have bothered with a bug report. -- Gad Abraham Dept. CSSE and NICTA The University of Melbourne Parkville 3010, Victoria, Australia email: [EMAIL PROTECTED] web: http://www.csse.unimelb.edu.au/~gabraham __ 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] format.factor (PR#11512)
Dear all,
differing from the standard behaviour of 'format' the current (2.7.0)
'format.factor' destroys attributes like 'dim' and 'dimnames'. This
unfortunately breaks some general code in the new package 'ff' for large
file-based data which will support vectors and arrays of atomic and factors.
It would be nice if you could include the following fix in the next release of
R.
Kind regards
Jens Oehlschlägel
format.factor <-
function (x, ...){
a <- attributes(x)
a$class <- NULL
a$levels <- NULL
x <- as.character(x)
attributes(x) <- a
format(x, ...)
}
> x <- factor(c("aa",letters[-1]))
> dim(x) <- c(13,2)
> format(x, justify="right")
[1] "aa" " b" " c" " d" " e" " f" " g" " h" " i" " j" " k" " l" " m" " n" " o"
" p" " q" " r" " s" " t" " u" " v" " w" " x" " y" " z"
>
> format.factor <-
+ function (x, ...){
+ a <- attributes(x)
+ a$class <- NULL
+ a$levels <- NULL
+ x <- as.character(x)
+ attributes(x) <- a
+ format(x, ...)
+ }
>
> format(x, justify="right")
[,1] [,2]
[1,] "aa" " n"
[2,] " b" " o"
[3,] " c" " p"
[4,] " d" " q"
[5,] " e" " r"
[6,] " f" " s"
[7,] " g" " t"
[8,] " h" " u"
[9,] " i" " v"
[10,] " j" " w"
[11,] " k" " x"
[12,] " l" " y"
[13,] " m" " z"
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 7.0
year 2008
month 04
day22
svn rev45424
language R
version.string R version 2.7.0 (2008-04-22)
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Macintosh Transperancy (PR#11511)
Bradley -- please learn the difference between 'transparent' and 'semi-transparent'/'translucent'. Your statements only begin to make sense for partially opaque colours. Furthermore, there was a bug in the handling of (fully) transparent colours for these pch's what has been fixed in R-patched. Also, the FAQ does ask you to make a bug report _only_ if you 'know for certain' what should happen, and here you are saying you would like to be able to do something different. (It also discusses how to make 'wishlist' proposals, but you did not follow that and such proposals need to be unambiguously documented.) You had better also 'know for certain' what does actually happen with current R versions. There are several ways to handle semi-transparency, and Paul Murrell and I have debated which is the correct one to use. In the case of pch=21:25 where there may be two semi-transparent colours to paint, it is pretty clear that sensible people expect the two colours to be painted separately (they need not even have the same opacity). If you don't want the border to be painted, make it transparent (and use R-patched or later). Where the issue is less clear-cut is in pch=16 or 19, where the disc does have a stroked border of the same colour. There devices do differ. So if I do plot(1, type="n") points(1,1,pch=16, cex=10, lwd=3, col="#0030") on pdf() I get a disc of uniform colour and AFAIR on all other devices which support transparency give a darker border. The point being that if we paint a fill and then a border in the same semi-transparent colour, should the overlap be painted once or twice? I've not yet convinced Paul that we should take a position on what should happen here (and the use of anti-aliasing on lines or even fills means that what actually happens on some devices is more complicated still--and more complicated again on monitors such as mine which have hardware sharpening). However, if you care you can use pch=21 with a transparent 'col' to achieve a uniform disc on all devices. On Sat, 24 May 2008, Simon Urbanek wrote: Bradley, On May 24, 2008, at 9:07 PM, Bradley Vance wrote: The bug is that the point that's being plotted is a single point, not a combination of two points, one that's just the outline, and one that's just the fill. It also doesn't look like we'd expect when you're debugging a plot. For example, let's say I create a plot, and notice that I can't see some of the points (due to other points being drawn on top of them). So I decide to make them transparent, so you can see where points over-lay each other, and the relative size/colors/etc of the over-layed points. Now, rather than just changing the opacity of the points/colors I see, I'm adding in another color to each point where outline and background meet, making the plot more confusing than it needs to be... In looking at the documentation for bg in points (plot says to look at points for bg) it says bgbackground (fill) color for the open plot symbols given by pch=21:25. and the way it is now, the color is not a fill (ie - inside the lines) - it's super-imposed over part of the line. I think you're still missing the point - it is the fill. I suspect you're misunderstanding the effect of using semi-transparent strokes. Moreover I get *exactly* the same result using X11 (both Mac *and* Linux) as well as other devices (PDF etc.). If you see anything else then *that* is a bug. A point is represented by a shape (path) which is filled and then drawn (line stroke). As I was trying to explain earlier the effect is that half of the line is in the filled area. Imagine a rectangle (0,0)-(1,1). When you fill it, you're filling strictly the area between 0 and 1 (in both x and y). However, when you strike let's say the line (0,0)-(1,0) with the width 0.25, you are filling the area (0,-0.25)-(1,+0.25) which means that half the line is outside (y<0) the filled are and another half is inside (y>=0). Given the alpha-blending mechanics [target=alpha*color + (1-alpha)*old] it implies that if the fill color is different from the background color and the line is not opaque, you get different color outside and inside the rectangle. You can verify that this is true for all devices that support alpha blending. This is how it works and is supposed to be, that's not a bug. Also, there's the fact that it does something different on different systems. When I do the same thing at work on a Linux box (we don't have R.2.7 yet, we use mostly R2.4 but I've tried it on R2.6, Well, 2.6 didn't have alpha support in X11 AFAIR, so I have no idea what you are trying to compare there ... and we don't have Quartz, but I did output to PDF), it looks like a single point whose colors were made transparent, and not a point made of two overlapping transparent parts. As I implied in my original ticket, I'd like to be able to choose whether to have it look the way it does now on the
