These are beta version because the help manuals are not written yet. Their functions are already matured to the releasse stage. I will put them to CRAN as soon as finishing help files, and that will be after a few weeks. Once submitted to CRAN, things will go slower. So reporting bugs or giving me any suggestions are especially welcomed before I submit them. Of course I will welcome your responses after the submission, too.
You can download them at:
Installation procedure is:
install.packages('/downloaded/folder/boxplotdbl_1.0.0.tar.gz', repos=NULL,type='source') library(boxplotdbl) install.packages('/downloaded/folder/diaplt_1.0.0.tar.gz', repos=NULL,type='source') library(diaplt)
Instructions are available in the source code located in R folder. Or following urls:
The boxplotdou function in boxplotdbl package is for,
To start quickly, I use here the built-in iris data frame. This is a paired data, but the boxplotdou is designed for two independent data frames combined by common factors.
boxplotdou(iris[c(5,1)],iris[c(5,3)])
boxplotdou(iris[c(5,2)],iris[c(5,4)])
The beadsplot function in diaplt package is for,
I developed this chart to look over a soil chemical component data between several sites.
beadsplot(iris[1:4],iris[5],scale.range=NULL,scale.mean=NULL)
beadsplot(iris[1:4],iris[5])
Statistics, genetics, programming, academics
R, Statistics
Pingback: boxplotdbl 1.2.2 and diaplt 1.2.1 packages are now available at CRAN | ЯтомизоnoR
Pingback: Double Box Plot package boxplotdbl 1.2.0 released | ЯтомизоnoR
The graphics look useful, but the interface looks very non-standard and error prone. It is not clear from the call what it is you are doing.
You need a more standard “formula and data.frame” interface to these functions for people to be able to use them safely and incorporate them into clear, self-documenting code.
Also, why are they in separate packages? It would be simpler to have them both in the same package.
Just my 2c.
Thanks, Bill.
Two reasons, not used the formula and data.frame.
1. That was not so useful for my case.
2. Because boxplotdou is for two data.frames, that needs two formulas. Not so smart.
The two functions are completely different and independent. I uploaded them at same time by chance.
There is no reason why boxplotdou needs to use two data frames, is there? They must be of the same row size and they must have a factor in common. That seems like a recipe for disaster to me. The code you give in your example is
boxplotdou(iris[c(5,2)],iris[c(5,4)])
What does that mean? Compare this with
boxplotdou(Species ~ Petal.Width + Sepal.Width, data = iris)
which it immediately clear what is going on.
There is a good principle in R programming: never use numerical indices if you can possibly use names. Numerical indices are really for interactive use of R only, i.e. for use between consenting adults in private.
I have to say I remain unconvinced by your reply. It looks like a kind of matlab style, something R is trying to improve upon.
Your two packages may be independent of each other, but they both provide graphical tools that do comparable, if not similar things, and they both depend on the same tools, principally ggplot2. Should ggplot2 come in multiple packages?
That probably take me up to 4c, I think!
Hi, Bill.
Well, I’ve got your point.
I designed boxplotdou to use two independent data frames. Unfortunately, I couldn’t find such built-in data. So I used iris data twice in my example. That’s not the best example. Something to start quickly.
Think we have another iris data, that name is iris4, having two columns, Species and Densities. Species is same as iris, and Densities have plant densities at natural habitats.
Better example is
boxplotdou(Petal.Width~Species, iris, Densities~Species, iris4)
I agree using names is good, but I don’t agree to prohibit numerical indices. I need the numerical interface.
Anyway I will add the formula interface as shown above. I understand that is useful.
Packages may be huge, or tiny. That is a matter of maintainers. If the maintainer of ggplot2 decide to divide the package into ggplot2 and ggplot2ext, that is acceptable for me. Also if ggplot2 become bigger including other packages, that will be ok. As a maintainer, I want to keep my packages small.
Well, I tried my best. I guess some advance is better than none. Sigh.
Incidentally, I never did suggest prohibiting numerical indices – that would be dumb – only discouraging their use *in scripts*, that is, in code other people may have to read and interpret.
Why sighing? You gave me a nice suggestion to improve these packages, and I’m thanking you about this.
Principles are beautiful, but the world is dirty and requires some discouraged codes.