Re: [Rd] prettyNum digits=0 not compatible with scientific notation

[Robert McGehee]

Hi,
Thanks for this. To be clear, I did not intend to use scientific notation, I 
just happened to stumble upon this when using prettyNum on numbers large enough 
that R switched to scientific notation and I noticed the problem. I just made 
this artificial example just to show with an example using smaller numbers (and 
in case someone on this list redefined their options(scipen) in their .Rprofile 
as I do).

Specifically, here's what I wanted to see:
> prettyNum(3000.9, big.marks=",", digits=0)
[1] "30,000,001"
But got "%#4.0-1e" instead. I was intending to use digits=0 as a way of 
rounding at the same time as adding commas, and was meaning to have a zero 
significant digit scientific notation thing, which I agree probably doesn't 
make sense.

Also, even smaller numbers that don't normally trigger scientific notation 
cause the odd output, so maybe this isn't strictly a scientific notation 
problem? 
> options(scipen=0)
> 12345.6
[1] 12345.6 # No scientific notation here
> prettyNum(12345.6, digits=0)
[1] "%#4.0-1e"

My "fix" is just to add scientific=FALSE to my prettyNum calls as this seems to 
make the problem disappear for me in all cases. However, the odd output I 
encountered along the way seemed worthy of comment.

HTH, Robert

-Original Message-
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch] 
Sent: Friday, March 22, 2019 5:11 AM
To: Robert McGehee 
Cc: r-devel@r-project.org
Subject: Re: [Rd] prettyNum digits=0 not compatible with scientific notation

Thank you, Robert for raising this here !

>>>>> Robert McGehee 
>>>>> on Thu, 21 Mar 2019 20:56:19 + writes:

> R developers,
> Seems I get a bad result ("%#4.0-1e" in particular) when trying to use 
prettyNum digits=0 with scientific notation. I tried on both my Linux box and 
on an online R evaluator and saw the same problem, so it's not limited to my 
box at least. I see the problem in both R 3.5.3 and R 3.3.2.

> options(scipen= -100)

The above is extreme: You're basically setting an option to
always see non-integer numbers in "scientific" format ..
But read below about what 'digits' means in this case.

> prettyNum(1, digits=0)
> [1] "%#4.0-1e"
> prettyNum(2, digits=0)
> [1] "%#4.0-1e"
> prettyNum(1, digits=0, scientific=FALSE) # Works
> [1] "1"
> prettyNum(1:2, digits=0) # Works
> [1] "1" "2"
> prettyNum(c(1.1, 2.1), digits=0)
> [1] "%#4.0-1e" "%#4.0-1e"
> prettyNum(c(1.1, 2.1), digits=1) # Works
> [1] "1e+00" "2e+00"

I'm the scape goat / culprit /.. : I have worked on tweaking the
formatting of (non integer) numbers in R for a long time, on the
way introducing prettyNum(), also already long ago...
but then it's actually not prettyNum() but rather format() here :

Have you read its help page - *with* care?

If you do, you'd notice that 'digits' is not among the formal arguments
of prettyNum() *and* that prettyNum() passes all its  `...`  to format().
And if you read  ?format [which then you should to understand 'digits' !]
you see

  > digits: how many significant digits are to be used for numeric and
  >  complex ‘x’.  The default, NULL, uses ‘getOption("digits")’.
>  This is a suggestion: enough decimal places will be used so that
  >  the smallest (in magnitude) number has this many significant 
  >  digits, and also to satisfy ‘nsmall’.

  >   [.]

So, for the real numbers you use in your example, digits are
*significant* digits as in  'options(digits= *)' or
'print(.., digits= *)'

-- Excursion about 'integer' and format()ing 
-- and you now may also understand why   prettyNum(1:2, digits=0)  works
 as you expect: integer formatting behaves differently   
 but I acknowledge that the  ?format   help page does not say so
 explicitly yet:  it 'real and complex' numbers for the
 'scientific' argument,  and 'numeric and complex' numbers for
 the 'format' argument.
 If you replac numeric by reald, what this entails (by logic)
 that 'integer' numbers are *not* affected by 'digits' nor  'scientific'.

 But there's yet more subtlety: 'integer' here means class/type "integer"
 and not just an integer number, i.e., the difference of  1L and 1 :

  > str(1)
   num 1
  > str(1L)
   int 1
  > str(1:3)
   int [1:3] 1 2 3
  > str(1:3 + 0)
   num [1:3] 1 2 3
  > 
-- end of Excursion{'integer' ..} ---

Back to real numbers : 'digits' are used as *significant* digits
(and are only a suggestion: format() and prettyNum() ensure
 a common width for their resulting strings so printing will be
nicely aligned), see e.g.

   > format(3.14, scientific=FALSE)
   [1] "3.14"
   > format(3

[Rd] prettyNum digits=0 not compatible with scientific notation

[Robert McGehee]

R developers,
Seems I get a bad result ("%#4.0-1e" in particular) when trying to use 
prettyNum digits=0 with scientific notation. I tried on both my Linux box and 
on an online R evaluator and saw the same problem, so it's not limited to my 
box at least. I see the problem in both R 3.5.3 and R 3.3.2.

options(scipen=-100)
prettyNum(1, digits=0)
[1] "%#4.0-1e"
prettyNum(2, digits=0)
[1] "%#4.0-1e"
prettyNum(1, digits=0, scientific=FALSE) # Works
[1] "1"
prettyNum(1:2, digits=0) # Works
[1] "1" "2"
prettyNum(c(1.1, 2.1), digits=0)
[1] "%#4.0-1e" "%#4.0-1e"
prettyNum(c(1.1, 2.1), digits=1) # Works
[1] "1e+00" "2e+00"

> R.version
   _   
platform   x86_64-pc-linux-gnu 
arch   x86_64  
os linux-gnu   
system x86_64, linux-gnu   
status 
major  3   
minor  5.3 
year   2019
month  03  
day11  
svn rev76217   
language   R   
version.string R version 3.5.3 (2019-03-11)
nickname   Great Truth 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] as.character(list(NA))

[Robert McGehee]

Also perhaps a surprise that the behavior depends on the mode of the NA. 

> is.na(as.character(list(NA_real_)))
[1] FALSE
> is.na(as.character(list(NA_character_)))
[1] TRUE

Does this mean deparse() preserves NA-ness for NA_character_ but not NA_real_?


-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Hervé Pagès
Sent: Monday, January 22, 2018 2:01 PM
To: William Dunlap ; Patrick Perry 
Cc: r-devel@r-project.org
Subject: Re: [Rd] as.character(list(NA))

On 01/20/2018 08:24 AM, William Dunlap via R-devel wrote:
> I believe that for a list as.character() applies deparse()  to each element
> of the list.  deparse() does not preserve NA-ness, as it is intended to
> make text that the parser can read.
> 
>> str(as.character(list(Na=NA, LglVec=c(TRUE,NA),
> Function=function(x){x+1})))
>   chr [1:3] "NA" "c(TRUE, NA)" "function (x) \n{\nx + 1\n}"
> 

This really comes as a surprise though since coercion to all the
other atomic types (except raw) preserve the NAs.

And also as.character(unlist(list(NA))) preserves them.

H.

> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> 
> On Sat, Jan 20, 2018 at 7:43 AM, Patrick Perry  wrote:
> 
>> As of R Under development (unstable) (2018-01-19 r74138):
>>
>>> as.character(list(NA))
>> [1] "NA"
>>
>>> is.na(as.character(list(NA)))
>> [1] FALSE
>>
>> __
>> R-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VbamM9XRQOlfBakrmlrmQZ7DLgXZ-hhhFeLD-fKpoCo=Luhqwpr2bTltIA9Cy7kA4gwcQh16bla0S6OVe3Z09Xo=
>>
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=VbamM9XRQOlfBakrmlrmQZ7DLgXZ-hhhFeLD-fKpoCo=Luhqwpr2bTltIA9Cy7kA4gwcQh16bla0S6OVe3Z09Xo=
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

__
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

Re: [Rd] 'gsub' not perl compatible?

[Robert McGehee]

Hi Jean-Luc,
FWIW, you're pointing out a common discrepancy between regex parsers, which is 
whether or not a regex parser advances after finding both a zero-length match 
and a non-zero-length match.

I think this article is especially helpful for understanding the nuances here, 
particularly the section "Advancing After a Zero-Length Regex Match". 
http://www.regular-expressions.info/zerolength.html

For this article, their test example was gsub("\\d*", "x", "x1"), which 
demonstrates the same difference as in your example (i.e. the answer can be 
either "xxx" or "" depending on the parser). They also specifically provide 
a note on R's gsub function that notes this discrepancy:

"The regexp functions in R and PHP are based on PCRE, so they avoid getting 
stuck on a zero-length match by backtracking like PCRE does. But the gsub() 
function to search-and-replace in R also skips zero-length matches at the 
position where the previous non-zero-length match ended, like Python does."

All that said, your larger point still seems valid, that we should expect to 
see behavior consistent with the PCRE parser when we specify perl=TRUE, even if 
that is a different answer than we get from R's default TRE parser when 
perl=FALSE. And to take perl out of the equation, I also verified your test 
directly with PCRE (8.39) on my Linux box using the `pcretest` command, and 
sure enough, pcretest shows four matches to your example, consistent with an 
answer of !a!!c! like you said. Perhaps at a minimum, the ?gsub or ?regex man 
page should add a blurb indicating that the perl=TRUE behavior differs from 
PCRE in the case of non-zero length matches adjacent to zero-length matches. 
Though I'm not sure if this difference is known and intentional or just a side 
effect of some other decision. R also supports adding perl options embedded in 
the pattern. For example '(?i)' makes the pattern case insensitive and '(?U)' 
turns of greedy matching. I could imagine having the behavior you noted d
 epend on such an option as well, if someone was inclined to make a patch and 
didn't want to change existing behavior.

However, to rewrite your query to get the result you want, it seems you may 
unfortunately have to rewrite the query using two calls to gsub using something 
like this: 

> gsub("b?", "!", gsub("b", "bb", "abc"))
 [1] "!a!!c!"

--Robert


-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Lipatz 
Jean-Luc
Sent: Friday, July 21, 2017 5:27 AM
To: r-devel@r-project.org
Subject: [Rd] 'gsub' not perl compatible?

Hi all,

Working on some SAS program conversions, I was testing this (3.4.0 Windows, but 
also 2.10.1 MacOsX):
gsub("b?","!","abc",perl=T)

which returns
[1] "!a!c!"

that I didn't understand.

Unfortunately, asked for the same thing SAS 9.4 replies : "!a!!c!", and so does 
Perl (Strawberry 5.26), a more logical answer for me.
Is there some problem with PCRE or some subtility that I didn't catch?

Results are similar with * instead of ?
and there is a similar issue with the lazy operator:
gsub("b??","!","abc",perl=T) gives : "!a!b!c!", while the other softwares give 
"!a!!!c!"


Thanks

Jean-Luc LIPATZ




[[alternative HTML version deleted]]

__
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

Re: [Rd] 'ordered' destroyed to 'factor'

[Robert McGehee]

Hi,
It's been my experience that when you combine or aggregate vectors of factors 
using a function, you should be prepared for surprises, as it's not obvious 
what the "right" way to combine factors is (ordered or not), especially if two 
vectors of factors have different levels or (if ordered) are ordered in a 
different way.

For instance, what would you expect to get from unlist() if each element of the 
list had different levels, or were both ordered, but in a different way, or if 
some elements of the list were factors and others were ordered factors?
> unlist(list(ordered(c("a","b")), ordered(c("b","a"
[1] ?

Honestly, my biggest surprise from your question was that unlist even returned 
a factor at all. For example, the c() function just converts factors to 
integers.
> c(ordered(c("a","b")), ordered(c("a","b")))
[1] 1 2 1 2

And here's one that's especially weird. When rbind() data frames with an 
ordered factor, you still get an ordered factor back, but the order may be 
different from either of the original orders:

> x1 <- data.frame(a=ordered(c("b","c")))
> x2 <- data.frame(a=ordered(c("a","b","c")))
> str(rbind(x1,x2)) #  Note b < a
 'data.frame':  5 obs. of  1 variable:
 $ a: Ord.factor w/ 3 levels "b"<"c"<"a": 1 2 3 1 2

Should rbind just have returned an integer like c(), or returned a factor like 
unlist(), or should it kept the result as an ordered factor, but ordered the 
result in a different way? I have no idea.

So in short, IMO, there are definitely inconsistencies in how ordered/factors 
are handled across functions, but I think it would be hard to point to any 
single function and say it is wrong or needs to be changed. My best advice, is 
to just be careful when combining or aggregating factors.
--Robert

-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of "Jens 
Oehlschlägel"
Sent: Friday, June 16, 2017 9:04 AM
To: r-devel@r-project.org
Cc: jens.oehlschlae...@truecluster.com
Subject: [Rd] 'ordered' destroyed to 'factor'

Dear all,
 
I don't know if you consider this a bug or feature, but it breaks reasonable 
code: 'unlist' and 'sapply' convert 'ordered' to 'factor' even if all levels 
are equal. Here is a simple example:

o <- ordered(letters)
o[[1]]
lapply(o, min)[[1]]  # ordered factor
unlist(lapply(o, min))[[1]]  # no longer ordered
sapply(o, min)[[1]]  # no longer ordered

Jens Oehlschlägel
 
 
P.S: The above examples are silly for simple reproduction. The current behavior 
broke my use-case which had a structure like this
 
# have some data
x <- 1:20
# apply some function to each element
somefunc <- function(x){
  # do something and return an ordinal level
  sample(o, 1)
}
x <- sapply(x, somefunc)
# get minimum result
min(x)
# Error in Summary.factor(c(2L, 26L), na.rm = FALSE) :
#   ‘min’ not meaningful for factors
 
 
> version
   _   
platform   x86_64-pc-linux-gnu     
arch   x86_64  
os linux-gnu   
system x86_64, linux-gnu   
status     
major  3   
minor  4.0     
year   2017    
month  04  
day    21  
svn rev    72570   
language   R   
version.string R version 3.4.0 (2017-04-21)
nickname   You Stupid Darkness

__
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

[Rd] Allow dot in RHS of update.formula's old formula

[Robert McGehee]

Feature request:

I want to use update.formula to subtract an intercept (or other) term from a 
formula with a dot on the RHS. However, as this causes an error, I propose a 
patch below.

Thus, I want:
> update.formula(y ~ ., ~ . -1)
[1] y ~ . - 1

Instead I get this error:
Error in terms.formula(tmp, simplify = TRUE) : 
  '.' in formula and no 'data' argument

While the error message isn't especially helpful (as I *cannot* currently pass 
in a data argument), the problem is that terms.formula inside update.formula 
does not allow a dot in the RHS of 'old' unless either a 'data' argument is 
passed in or 'allowDotAsName=TRUE'. 

Thus, I'd like to suggest this change to update.formula to allow a dot in the 
RHS of old without (I believe) impacting any other behavior.

-out <- formula(terms.formula(tmp, simplify = TRUE))
+out <- formula(terms.formula(tmp, simplify = TRUE, allowDotAsName=TRUE))

If this is undesirable for some reason, then alternatively the dots argument of 
update.formula could be passed to terms.formula so the user could pass in 
either 'data' or 'allowDotAsName=TRUE' themselves (though as I cannot think of 
any reason the user would prefer 'allowDotAsName=FALSE', this is not my 
preference).

-out <- formula(terms.formula(tmp, simplify = TRUE))
+out <- formula(terms.formula(tmp, simplify = TRUE, ...))

>From my reading of the Details section of ?update.formula, it seems as if this 
>suggestion is consistent with the current documentation, as no mention is made 
>of dots in the RHS of 'old', and no mention is made of why this behavior 
>should be otherwise prohibited. If neither change is desirable for some 
>reason, then the update.formula documentation should at least point out this 
>exception (e.g. "... and substitutes the _rhs_ of the 'old' formula for any 
>occurrence of '.' on the right of 'new' *except if there is a dot in the _rhs_ 
>of 'old'*."

Thanks, Robert

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Very hard to reproduce bug (?) in R-devel

[Robert McGehee]

Winston,
I had a similar experience to you tracking down an insanely difficult bug in my 
R code that "disappeared" whenever slight changes were made to the script (e.g. 
like adding cat() statements). In my case, it coincided with my over-eager 
compilation of R and its library stack, as I was also experimenting with a 
cutting edge version of the gcc compiler as well as what I thought were 
innocuous performance enhancing CFLAGS like -O3/-Ofast -march=native. After 
downgrading gcc and recompiling everything (R and BLAS) without the extra 
flags, the problem went away. Not saying this is your problem, just sharing my 
similar experience.

 And for anyone interested, I did extensive benchmarking on the 
effects of the added CFLAGS and cutting edge gcc compilers, and I never saw any 
significant performance enhancement, and frequently saw a big performance 
penalty with extra flags, particularly as matrix algebra problems sometimes 
slowed down enormously when using a custom BLAS (ATLAS) compiled with anything 
fancy. Though nowadays, the out-of-the-box R BLAS seems much faster than it 
used to be, so I don't even bother fiddling with a custom BLAS. 

--Robert
 

-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Winston Chang
Sent: Wednesday, April 05, 2017 2:41 PM
To: Martin Maechler 
Cc: R Development 
Subject: Re: [Rd] Very hard to reproduce bug (?) in R-devel

)

On Wed, Apr 5, 2017 at 2:59 AM, Martin Maechler
 wrote:
>
> > Winston Chang 
> > on Tue, 4 Apr 2017 15:29:40 -0500 writes:
>
> > I've done some more investigation into the problem, and it is very
> > difficult to pin down. What it looks like is happening is roughly like 
> this:
> > - `p` is an environment and `p$e` is also an environment.
> > - There is a loop. In each iteration, it looks for one item in `p$e`, 
> saves
> > it in a variable `x`, then removes that item from `p$e`. Then it invokes
> > `x()`. The loop runs again, until there are no more items in `p$e`.
>
> > The problem is that `ls(p$e)` sometimes returns the wrong values -- it
> > returns the values that it had in previous iterations of the loop. The
> > behavior is very touchy. Almost any change to the code will slightly 
> change
> > the behavior; sometimes the `ls()` returns values from a different
> > iteration of the loop, and sometimes the problem doesn't happen at all.
>
> > I've put a  Dockerfile and instructions for reproducing the problem 
> here:
> > https://gist.github.com/wch/2596a1c9f1bcdee91bb210c782141c88
>
> > I think that I've gotten about as far with this as I can, though I'd be
> > happy to provide more information if anyone wants to take look at the
> > problem.
>
> Dear Winston,
>
> While I agree this may very well be a bug in R(-devel), and hence
> also R in 3.4.0 alpha and hence quite important to be dealt with,
>
> your code still involves 3 non-trivial  packages (DBI, R6,
> testthat) some of which have their own C code and notably load
> a couple of other package's namespaces.
> We've always made a point
>   https://www.r-project.org/bugs.html
> that bugs in R should be reproducible without extra
> packages... and I think it would definitely help to pinpoint the
> issue to be seen outside of your extra packages' world.
>
> Or have you been aware of that and are just asking for help
> finding a bug in one of the extra packages involved, a bug that might only be 
> triggered by recent changes in R ?
>
> OTOH, what you describe above  (p ; p$e ; p$e$x ...)
> should be reproducible in pure "base" R code, right?
>
> I'm sorry not to be of more help
> Martin


Of the four packages that are loaded when running the tests (pool,
DBI, R6, testthat, magrittr, crayon), only testthat contains compiled
code, and it is pretty minimal. The only compiled code in testthat
that should be executed is a function that finds a label -- but that
happens only after an error occurs.

This is the sessionInfo():
R Under development (unstable) (2017-03-23 r72389)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS: /usr/local/lib/R/lib/libRblas.so
LAPACK: /usr/local/lib/R/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] pool_0.1.0 DBI_0.6-1  testthat_1.0.2

loaded via a namespace (and not attached):
[1] compiler_3.5.0 magrittr_1.5   R6_2.2.0   crayon_1.3.2


I have spent days trying to make a 

Re: [Rd] non-infectious license for R package?

[Robert McGehee]

I have no direct experience in this regard, but this FAQ seems to answer your 
question. 
https://www.gnu.org/licenses/gpl-faq.en.html#IfInterpreterIsGPL

I read this to mean that the answer may be different depending on whether your 
code links against R libraries or simply uses R as an interpreter.

PS. "Infect" is an interesting choice of words in your email :)
--Robert

-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Mario 
Emmenlauer
Sent: Friday, March 24, 2017 9:53 AM
To: r-devel@r-project.org
Subject: [Rd] non-infectious license for R package?


Dear All,

I've been following this mailing list for over three years now, but its just 
now that I have realized that R is licensed under GPL! :-)

I'm not a lawyer and I don't want lawyer advice, but I'd like to get your 
feedback on a license question. My goal is to develop commercial software for 
image analysis of biomedical samples that may be used i.e. in academic 
institutions. Since I've been an academic software developer for long, a 
priority for me is to make the data and tools easily accessibly for other 
developers. I have toyed with the idea to make a (free) R package that can very 
efficiently fetch data from the database and push back results for 
visualization. To clarify: I am not using R in my software. I'd rather like the 
institutions of my customers to have open (internal) access to their data.

Now for the question: To efficiently get the data into R, I assume a package 
(possibly in C or C++) is the most reasonable way? If yes, would such a package 
automatically be infected by the GPL? If the package links to (proprietary 
closed source) libraries to efficiently access the data, would the libraries in 
turn be infected?

I'm asking this very naiively because I understand statement [1] in such a way 
that it is generally encouraged to make data available in R. Obviously open 
source is the preferred way, but my understanding is that also closed source 
extensions can add value and may be welcome.

I was therefore hoping that somebody has prior experience in this regard, or 
can shed further light on statement [1]. Is the R-C- interface infectious per 
se, even when data flows only into R, not vice versa? If its infectious, could 
just the very core of R be licensed additionally under a non-infectious license?

Furthermore, can I avoid infecting my full software stack, for example by 
making only the package open source under a permissive license? Are there any 
guidelines how to legally bridge between the proprietary and the R-world? I 
guess other people have tried this before, can someone share his/her experience?

[1] https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html

All the best,

Mario Emmenlauer

__
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

Re: [Rd] Matrix package breaks as.matrix method

[Robert McGehee]

Georgi,
Brilliant, thank you very much for the helpful reply and explanation! I added 
'importFrom("Matrix","as.matrix")'  to my NAMESPACE and all worked fine! As my 
'as.matrix' method is used entirely internally to the 'testmat' function (and 
not "used outside the package"), I don't think I actually need to export it. In 
my case, testmat is defined inside the package, and not in the global workspace 
(nothing is defined in the global workspace in my example).
 
To your point that I should just "import the 'Matrix'", I thought adding Matrix 
to the Depends field in the DESCRIPTION would do that for me, but apparently I 
need to study the WRE manual more thoroughly, as it clearly does not. 

It's also worth pointing out that R CMD check did not actually warn that I 
should have imported as.matrix, at least in the case where I have 'Depends: 
Matrix' in DESCRIPTION and only 'exportPattern("^[[:alpha:]]+")' in the 
NAMESPACE file. 

Last, for anyone who took issue, apologies for implying a bug where none 
exists, or that there was something wrong with Matrix or S4.

Thanks again, 
Robert

-Original Message-
From: Georgi Boshnakov [mailto:georgi.boshna...@manchester.ac.uk] 
Sent: Sunday, January 29, 2017 1:40 PM
To: r-devel@r-project.org
Cc: Robert McGehee <rmcge...@walleyetrading.net>
Subject: RE: R-devel Digest, Vol 167, Issue 25

Hi,

Short answer: import 'as.matrix'  and export your method(s) for it. From WRE:

"All S4 classes to be used outside the package need to be listed in an 
exportClasses directive. Alternatively, they can be specified using 
exportClassPattern.(46) in the same style as for exportPattern. To export 
methods for generics from other packages an exportMethods directive can be 
used."

Details: the precise details depend on what exactly is in your NAMESPACE file. 
The curious difference you observe is due to the fact that as.matrix is defined 
in 'base' as S3 generic.  
When you set an S4 method for it you effectively create your own as.matrix S4 
generic and your settings in NAMESPACE probably export everything you "own".

When you depend on package 'Matrix',  'as.matrix' is made S4 generic by it and 
you are defining a method for An imported function, so you need to use 
exportMethods (see the above excerpt), otherwise your method is not exported. 
(Indeed, in your example the arror is from array() in the default method).

Note also that it matters where you define the test function. I am pretty sure 
that you defined it in the global workspace (not in the package) to get the 
error.

It is very useful practice to run 'R CMD check' (or its devtools equivalent). 
In this case it would have warned you to import as.matrix. Also, to make your 
life easier during initial development, import the whole 'Matrix' and when 
things work think about cleaning up and importing only stuff that you need.

 
Best regards,
Georgi Boshnakov

------

Message: 15
Date: Fri, 27 Jan 2017 22:41:10 +
From: Robert McGehee <rmcge...@walleyetrading.net>
To: "r-devel@r-project.org" <r-devel@r-project.org>
Subject: [Rd] Matrix package breaks as.matrix method
Message-ID:

<30d28a63376088428e8318dd67fd407f705...@ny-mailstore1.walleyetrading.net>

Content-Type: text/plain; charset="us-ascii"

Hi,
The Matrix package and the as.matrix method do not seem to be compatible inside 
of a package.

Here's an example. I've created a simple package "mat" that defines an 
eponymous class and as.matrix method on that class. All is well, unless that 
package has the Matrix package in its Depends or Imports (and imports, e.g. the 
"Diagonal" function). Then my as.matrix method stops working, even if I'm not 
using any part of the Matrix package.

Here's an example on R 3.3.2:

First, create an empty package "mat" (e.g. with package.skeleton) with one file 
in mat/R/mat.R with the following contents:

setClass("mat", representation(H="matrix")) mat <- function(H) new("mat", H=H) 
setMethod("as.matrix", signature("mat"), function(x, ...) crossprod(x@H)) 
testmat <- function() {
H <- matrix(1:3, 1, 3)
M <- mat(H)
as.matrix(M)
}

Then install the mat package :
> require(mat)
> testmat()
 [,1] [,2] [,3]
[1,]123
[2,]246
[3,]369

All works fine!

Now add "Depends: Matrix" into the package's DESCRIPTION file (alternatively 
add "Imports: Matrix" and 'importFrom("Matrix","Diagonal")' in the NAMESPACE).

Try again:
> require(mat)
> testmat()
Error in as.vector(data) : 
  no method for coercing this S4 class to a vector

Bug? If not, can anyone provide a work around? In my case, I'd like to mix 
matrix and Matrix functions in my package, but am obviously having difficult

[Rd] Matrix package breaks as.matrix method

[Robert McGehee]

Hi,
The Matrix package and the as.matrix method do not seem to be compatible inside 
of a package.

Here's an example. I've created a simple package "mat" that defines an 
eponymous class and as.matrix method on that class. All is well, unless that 
package has the Matrix package in its Depends or Imports (and imports, e.g. the 
"Diagonal" function). Then my as.matrix method stops working, even if I'm not 
using any part of the Matrix package.

Here's an example on R 3.3.2:

First, create an empty package "mat" (e.g. with package.skeleton) with one file 
in mat/R/mat.R with the following contents:

setClass("mat", representation(H="matrix"))
mat <- function(H) new("mat", H=H)
setMethod("as.matrix", signature("mat"), function(x, ...) crossprod(x@H))
testmat <- function() {
H <- matrix(1:3, 1, 3)
M <- mat(H)
as.matrix(M)
}

Then install the mat package :
> require(mat)
> testmat()
 [,1] [,2] [,3]
[1,]123
[2,]246
[3,]369

All works fine!

Now add "Depends: Matrix" into the package's DESCRIPTION file (alternatively 
add "Imports: Matrix" and 'importFrom("Matrix","Diagonal")' in the NAMESPACE).

Try again:
> require(mat)
> testmat()
Error in as.vector(data) : 
  no method for coercing this S4 class to a vector

Bug? If not, can anyone provide a work around? In my case, I'd like to mix 
matrix and Matrix functions in my package, but am obviously having difficulty.

I've come across a somewhat similar report on stackoverflow 
http://stackoverflow.com/questions/13812373/overloading-operator-in-r-s4-classes-and-matrix-package
 regarding defining the "+" operator with the Matrix package, but I don't think 
the solution or the problem quite applies.

Thanks in advance, Robert

> R.version
   _   
platform   x86_64-pc-linux-gnu 
arch   x86_64  
os linux-gnu   
system x86_64, linux-gnu   
status 
major  3   
minor  3.2 
year   2016
month  10  
day31  
svn rev71607   
language   R   
version.string R version 3.3.2 (2016-10-31)
nickname   Sincere Pumpkin Patch   

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] S4 object does not commute? (PR#13209)

[Robert . McGehee]

Hello all,
It appears that for the simplest of S4 objects, z+1 does not equal 1+z.
Presumably this is a bug, as 1+z seems to make a malformed object (at
least malformed as an input to str).
Thanks, Robert


 setClass(test, representation(vector))
[1] test
 z - new(test, 1)
 identical(z+1, 1+z)
[1] FALSE
 str(z+1)
Formal class 'test' [package .GlobalEnv] with 1 slots
  ..@ .Data: num 2
 str(1+z)
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 'test' Class 'test' Class 'test' Class 'test' Class
'test' Class 'test' Class 'test' Class 'test' Class 'test' Class 'test'
Class 'test' Class 

[Rd] sapply(Date, is.numeric) (PR#12008)

[robert . mcgehee]

Full_Name: Robert McGehee
Version: 2.7.1
OS: Windows
Submission from: (NULL) (192.223.226.6)


R-developers,
The results below seem inconsistent. From the documentation for is.numeric, I
expect FALSE in both cases.

 x - data.frame(dt=Sys.Date())
 is.numeric(x$dt)
[1] FALSE
 sapply(x, is.numeric)
  dt
TRUE

## Yet, sapply seems aware of the Date class
 sapply(x, class)
  dt
Date

Thanks,
Robert

PS. Sorry if this sent twice. I originally sent this on Monday to
[EMAIL PROTECTED], but it didn't seem to go through. Perhaps it's a
deprecated  email address (?).

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] sapply(Date, is.numeric) (PR#11982)

[Robert . McGehee]

R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.

 x - data.frame(dt=3DSys.Date())
 is.numeric(x$dt)
[1] FALSE
 sapply(x, is.numeric)
  dt
TRUE

## Yet, sapply seems aware of the Date class
 sapply(x, class)
  dt
Date

Thanks,

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended fo...{{dropped:13}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] sapply(Date, is.numeric) (PR#12221)

[Robert . McGehee]

FYI,=20
I've tried posting the below message twice to the bug tracking system,
once by email (below), and the second time 5 days later directly to the
bugs.r-project.org website. As far as I can tell, the bug tracking
system hasn't picked this up. Also it looks like the latest incoming
bug is dated 25 May 2008, so perhaps others are having difficulty as
well. (cc: r-bugs)

Cheers, Robert


-Original Message-
From: McGehee, Robert=20
Sent: Monday, July 14, 2008 9:51 AM
To: [EMAIL PROTECTED]
Subject: sapply(Date, is.numeric)

R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.

 x - data.frame(dt=3DSys.Date())
 is.numeric(x$dt)
[1] FALSE
 sapply(x, is.numeric)
  dt
TRUE

## Yet, sapply seems aware of the Date class
 sapply(x, class)
  dt
Date

platform   i386-pc-mingw32=20
arch   i386   =20
os mingw32=20
system i386, mingw32  =20
status=20
major  2  =20
minor  7.0=20
year   2008   =20
month  04 =20
day22 =20
svn rev45424  =20
language   R  =20
version.string R version 2.7.0 (2008-04-22)

Thanks,

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended fo...{{dropped:12}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] seq.Date not accepting NULL length.out (PR#9239)

[Robert . McGehee]

There seems to be a bug in seq.Date such that it will not allow the user
to pass in length.out =3D NULL, despite the fact that this is the =
default
argument.

For example:
 dt1 - as.Date(2004-12-31)
 dt2 - as.Date(2005-12-31)
 seq.Date(dt1, dt2, length.out =3D NULL, by =3D month)
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1

This might be an issue if I want to wrap seq.Date in another function
that reports or modifies on length.out. For instance, suppose I want to
create a simple function that simply reports when length.out is NULL (or
missing), as below, but otherwise works identically to seq.Date.

FUN - function(to, from, length.out =3D NULL, by, ...) {
if (is.null(length.out)) cat(length.out is missing\n)
seq.Date(to, from, length.out =3D length.out, by =3D by, ...)
}

 seq.Date(dt1, dt2, by =3D month)
 [1] 2004-12-31 2005-01-31 2005-03-03 2005-03-31 2005-05-01
 [6] 2005-05-31 2005-07-01 2005-07-31 2005-08-31 2005-10-01
[11] 2005-10-31 2005-12-01 2005-12-31

 FUN(dt1, dt2, by =3D month)
length.out is missing
Error in seq.Date(dt1, dt2, length.out =3D NULL, by =3D day) :=20
'length.out' must be of length 1

I believe the patch to fix this error is as follows (on R2.4.0(alpha)
Revision 39430)
-   }  else if (!missing(length.out)) {
+   }  else if (!missing(length.out)  !is.null(length.out)) {

Another (perhaps better) patch would be to not have NULL be the default
for length.out.

HTH,
Robert

Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended for us...{{dropped}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Bug in title() crashes R (PR#9115)

[Robert . McGehee]

Hello,

The below reliably crashes R 2.3.1:
 plot.new()
 title(1:10)
Process R segmentation fault (core dumped) ...

Also, R will crash when these vectors are much smaller, just not as
reliably.

I haven't tried this in on today's snapshot, but didn't see anything in
the changelog that seems to have addressed this.

HTH,
Robert

 R.version
   _=20
platform   i386-pc-mingw32  =20
arch   i386 =20
os mingw32  =20
system i386, mingw32=20
status  =20
major  2=20
minor  3.1  =20
year   2006 =20
month  06   =20
day01   =20
svn rev38247=20
language   R=20
version.string Version 2.3.1 (2006-06-01)

Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended for us...{{dropped}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Typo in getAllMethods() (PR#8848)

[Robert . McGehee]

This is a multi-part message in MIME format.

--_=_NextPart_001_01C67389.C6480D9F
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The function getAllMethods in the methods package uses the non-existent
function packageName where I believe the function getPackageName was
intended.=20

For example:

 getAllMethods(formula)
Error in sprintf(gettext(fmt, domain =3D domain), ...) :=20
could not find function packageName

The patch to RMethodUtils.R is here:

  238c238
   warning(gettextf('%s' from '%s' is a non-generic function;
no methods available, f, packageName(gwhere)), domain =3D NA)
---
   warning(gettextf('%s' from '%s' is a non-generic function;
no methods available, f, getPackageName(gwhere)), domain =3D NA) =20

 R.version
   _=20
platform   i386-pc-mingw32  =20
arch   i386 =20
os mingw32  =20
system i386, mingw32=20
status  =20
major  2=20
minor  3.0  =20
year   2006 =20
month  04   =20
day24   =20
svn rev37909=20
language   R=20
version.string Version 2.3.0 (2006-04-24)

Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



 This e-mail, and any attachments hereto, are intended for use by the
 addressee(s) only and may contain information that is (i) confidential
 information of Geode Capital Management, LLC and/or its affiliates,
 and/or (ii) proprietary information of Geode Capital Management, LLC
 and/or its affiliates. If you are not the intended recipient of this
 e-mail, or if you have otherwise received this e-mail in error, please
 immediately notify me by telephone (you may call collect), or by
 e-mail, and please permanently delete the original, any print outs and
 any copies of the foregoing. Any dissemination, distribution or
 copying of this e-mail is strictly prohibited.=20
=20

--_=_NextPart_001_01C67389.C6480D9F
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN
HTML
HEAD
META HTTP-EQUIV=3DContent-Type CONTENT=3Dtext/html; =
charset=3Dus-ascii
META NAME=3DGenerator CONTENT=3DMS Exchange Server version =
6.0.6617.90
TITLETypo in getAllMethods()/TITLE
/HEAD
BODY
!-- Converted from text/rtf format --

PFONT SIZE=3D2 FACE=3DCourier NewThe function getAllMethods in the =
methods package uses the non-existent function packageName where I =
believe the function getPackageName was intended. /FONT/P

PFONT SIZE=3D2 FACE=3DCourier NewFor example:/FONT
/P

PFONT SIZE=3D2 FACE=3DCourier Newgt; =
getAllMethods(quot;formulaquot;)/FONT

BRFONT SIZE=3D2 FACE=3DCourier NewError in sprintf(gettext(fmt, =
domain =3D domain), ...) : /FONT

BRnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; FONT SIZE=3D2 =
FACE=3DCourier Newcould not find function =
quot;packageNamequot;/FONT
/P

PFONT SIZE=3D2 FACE=3DCourier NewThe patch to RMethodUtils.R is =
here:/FONT
/P

PFONT SIZE=3D2 FACE=3DCourier Newnbsp; 238c238/FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newlt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; =
warning(gettextf(quot;'%s' from '%s' is a non-generic function; no =
methods availablequot;, f, packageName(gwhere)), domain =3D =
NA)/FONT/P

PFONT SIZE=3D2 FACE=3DCourier New---/FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newgt;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; =
warning(gettextf(quot;'%s' from '%s' is a non-generic function; no =
methods availablequot;, f, getPackageName(gwhere)), domain =3D =
NA)nbsp; /FONT/P

PFONT SIZE=3D2 FACE=3DCourier Newgt; R.version/FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;n=
bsp;nbsp;nbsp; =
_nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; =
/FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newplatformnbsp;nbsp;nbsp;nbsp;nbsp;nbsp; =
i386-pc-mingw32nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbs=
p; /FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newarchnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; =
i386nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nb=
sp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newosnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=
nbsp; =
mingw32nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /FONT

BRFONT SIZE=3D2 FACE=3DCourier =
Newsystemnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; i386, =
mingw32nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;=
nbsp; /FONT

BRFONT SIZE=3D2 FACE=3DCourier

[Rd] read.table error upon package installation (PR#8230)

[Robert . McGehee]

Upon upgrading to R 2.2.0 on my Windows box, I found that one of my
packages no longer compiled, giving this error:

Error in read.table(zfile, header =3D TRUE) :
more columns than column names
Execution halted

After removing every line of code from my package and still not being
able to compile it, I found the error to be related to a .txt file in my
data directory. I reduced my data file to a very simple example which
causes the error, and a nearly identical file which does not cause the
problem.

A file with these contents causes the error (I am using \t to indicate
the usual tab delimiter).
x   \t  y
A B C   \t  DEF

However, if I remove one of the spaces between A and B or B and C, the
package compiles fine:
x   \t  y
A BC\t  DEF

I can only guess that there is some kind of parsing problem when there
is more than one space between tab delimiters.

Robert

 version
 _ =20
platform i386-pc-mingw32
arch i386  =20
os   mingw32   =20
system   i386, mingw32 =20
status =20
major2 =20
minor2.0   =20
year 2005  =20
month10=20
day  06=20
svn rev  35749 =20
language R=20

This e-mail, and any attachments hereto, are intended for us...{{dropped}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel