Peter,
Thanks for the response. I have no wish to prolong this and have no axe to
grind. I’m sure you were delighted to see another stringsAsFactors issue.
Perhaps we talking about the conflation of two steps: the first is the language
‘pure' conversion of the table to a data.frame with the cros
I have to disagree with both Peter and Martin on this.
The underneath issue is that the automatic conversion of characters to factors
by the
data.frame functions was the single most egregious design blunder in the
Statistical
Models in S book, and we are still living with it. The stringsAsFac
My point was that, in a table, the row and columns usually have a well-defined
order. If you convert the table to data frame form, typically in order to fit a
Poisson GLM, you do want to preserve that order, and not have the levels
converted to a locale-dependent alphabetical order in your analy
Please refer to the documentation (?stop, ?recover, ?dump.frames). In
non-interactive use, recover() works as dump.frames(). dump.frames() is
documented not to quit R, and the examples show how to quit the R
session with a given status automatically after dump.frames(). So in
line with the d
Peter, we are arguing at cross purposes. My point was that if I have specified
options(stringsAsFactors=FALSE) that is a statement to R to NOT DO THIS. Your
argument
in return is that "yes, Therneau said that, but in this case he almost
certainly doesn't
really mean it, so ignore him". Now
Note that I sent this to r-devel, yesterday.
However, it didn't appear on the mailing list.
So, I'm resending it.
Today, I plotted the following:
> filled.contour (,,z, color.palette=terrain.colors)
It looked OK, in R.
However, when I created a PDF document, the plot (and other similar plots)
had
