[Rd] Inconsistency, may be bug in read.delim ?
Dear friends,
I stumbled into beheaviour of read.delim which I would consider a bug
or at least an inconsistency that should be improved upon.
Recently we had to work with data that used "", two double quotes, as
symbol to start and end character input.
Essentially the data looked like this
data.csv
V1, V2, V3
""data"", 3,
The last sequence of indicating a missing.
One obvious solution to read in this data is using some gsub(),
but that's not the point I want to make.
Consider this case we found during tests:
test.csv
V1, V2, V3, V4
, , 3, ""
and read it with
> read.delim("test.csv", sep=",", header=TRUE, na.strings="\"")
you get the following
V1 V2 V3 V4
1 NA " 3 NA
(and a warning)
I would have assumed to get some error message or at
least the same result for both appearances of in the
input file.
(the setting na.strings="\"" turned out to be working for
a colleague and his specific data, while I think it shouldn't)
My main concern is the different interpretation for the two
sequences.
Real bug? Minor inconsistency? I don't know.
All the best
Detlef
--
'People who say "I have nothing to hide" misunderstand the purpose of
surveillance. It was never about privacy. It's about power.' E. Snowden
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo in man/pretty.Rd
patch against recent SVN ...
as far as I can tell this trivial typo has been there for 20 years:
https://github.com/wch/r-source/blame/ba7920a99fb2fb62b89e404e65f8b132ed4c150a/src/library/base/man/pretty.Rd
===
--- pretty.Rd (revision 74426)
+++ pretty.Rd (working copy)
@@ -21,8 +21,8 @@
\item{min.n}{nonnegative integer giving the \emph{minimal} number of
intervals. If \code{min.n == 0}, \code{pretty(.)} may return a
single value.}
- \item{shrink.sml}{positive numeric
-by a which a default scale is shrunk in the case when
+ \item{shrink.sml}{positive numeric factor
+by which a default scale is shrunk in the case when
\code{range(x)} is very small (usually 0).}
\item{high.u.bias}{non-negative numeric, typically \eqn{> 1}.
The interval unit is determined as \{1,2,5,10\} times \code{b}, a
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] BUG: tools::pskill() returns incorrect values or non-initated garbage values [PATCH]
Thanks for spotting this, fixed in R-devel (including the Windows version).
Tomas
On 03/18/2018 09:53 PM, Henrik Bengtsson wrote:
For the record, I've just filed the following bug report with a patch
to https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17395:
tools::pskill() returns either random garbage or incorrect values,
because the internal ps_kill() (a) it does not initiate the returned
logical, and (b) it assigns the logical returned the 0/-1 value of C's
kill().
# Example 1: returns garbage due to non-initiated allocation
as.integer(tools::pskill(0))
[1] 44764824
as.integer(tools::pskill(0))
[1] 41609736
as.integer(tools::pskill(0))
[1] 45003984
# Example 2: returns 0 in success and -1 on failure
p <- parallel::mcparallel({ Sys.sleep(3600); 42L })
res <- tools::pskill(pid = p$pid, signal = tools::SIGKILL)
as.integer(res)
[1] 0
p <- parallel::mcparallel({ Sys.sleep(3600); 42L })
res <- tools::pskill(pid = p$pid, signal = -1) ## invalid signal
as.integer(res)
[1] -1
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
