[Rd] Re-attaching a package environment drops the attributes
Hi.
contrary to other environments, the attributes of a *package*
environment are dropped (from the new environment) when attach():ing
it to the search() path. This might or might not be surprising, but
have some side effects if rearranging/attaching package environments.
# Example - Regular environments
env <- new.env()
attr(env, "foo") <- "bar"
print(env)
##
## attr(,"foo")
## [1] "bar"
attach(env, pos=2, name="foo", warn.conflicts=FALSE)
env2 <- as.environment("foo")
print(env2)
##
## attr(,"name")
## [1] "foo"
# Example - Package environments
env <- as.environment("package:utils")
attr(env, "foo") <- "bar"
print(env)
##
## attr(,"name")
## [1] "package:utils"
## attr(,"path")
## [1] "C:/PROGRA~1/R/R-2.6.0alpha/library/utils"
## attr(,"foo")
## [1] "bar"
attach(env, pos=2, name="package:utils2", warn.conflicts=FALSE)
env2 <- as.environment("package:utils2")
print(env2)
##
## attr(,"name")
## [1] "package:utils2"
This becomes a problem, because the 'path' attribute is dropped causing:
packageDescription("utils2")
## Error in if (pkgpath == "") { : argument is of length zero
sessionInfo()
## Error in if (pkgpath == "") { : argument is of length zero
Again, this might or might not expected.
Finally:
> sessionInfo()
R version 2.6.0 alpha (2007-09-14 r42843)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Date vs date (long)
On 9/17/07, Terry Therneau <[EMAIL PROTECTED]> wrote:
> Gabor Grothendieck
>
> as.Date(10)
> You can define as.Date.numeric in your package and then it will work. zoo
> has done that.
>
> library(zoo)
> as.Date(10)
>
> This is also a nice idea. Although adding to a package is possible, it is
> now very hard to take away, given namespaces. That is, I can't define my
> own Math.Date to do away with the creation of timespan objects. Am I
> correct? Is it also true that adding methods is hard if one uses version 4
> classes?
>
> The rest of Gabor's comments are workarounds for the problem I raised.
> But I don't want to have to wrap "as.numeric" around all of my date
> calculations.
You can define as.Date.numeric and Ops.Date, say, using S3 and these
will be added to the whatever is there but won't override the existing
+.Date and -.Date nor would you want them to or else the behavior would
be different depending on whether your package was there or not. Also
namespaces should not be a problem since zoo uses namespaces and
it defined its own as.Date.numeric.
Try this:
Ops.Date <- function (e1, e2) {
e <- if (missing(e2)) {
NextMethod(.Generic)
}
else if (any(nchar(.Method) == 0)) {
NextMethod(.Generic)
}
else {
e1 <- as.numeric(e1)
e2 <- as.numeric(e2)
NextMethod(.Generic)
}
e
}
Sys.Date() / Sys.Date()
Sys.Date() + as.numeric(Sys.Date())
as.numeric(Sys.Date()) + as.numeric(Sys.Date())
Sys.Date() + Sys.Date() # error since its intercepted by +.Date
Thus you will have to issue some as.numeric calls but perhaps not too
many.
However, I think its better not to implement Ops.Date as above but
just leave the Date operations the way they are, extend it with
as.Date.numeric like zoo has done and force the user to use as.numeric
in other cases to make it clear from the code that there is conversion
going on. I have done a fair amount of Date manipulation and have not
found the as.numeric to be onerous.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Date vs date (long)
Terry Therneau wrote:
> b. "I'd advise against numeric operation on difftime objects in general,
> because of the unspecified units."
> If I carry this idea forward, the R should insist that I specify units for
> any variable that corresponds to a physical quantity, e.g. "height" or
> "weight", so that it can slap my hands with an error message when I type
>
> bodyMassIndex = weight/ height^2
>
> or cause plot(height^2, weight) to fail. This would go a long way towards
> making R the most frustrating program available. (An Microsoft gives some
> stiff competition in that area!)
>
That's not the point. The point is that 2 weeks is 14 days, so do you
want sqrt(2) or sqrt(14)? It is not my design to have this
variable-units encoding of difftimes, but as it is there, it is better
to play along than to pretend that it is something else. (Once you go to
faster time scales than in epidemiology, this becomes quite crucial
because the units chosen can depend on the actual differences computed!)
> c.
> "It is assumed that the divisor is unit-less.
> Convert to numeric first to avoid this. (The idea has been raised to
> introduce new units: epiyears and epimonths, in which case you might do
>
> x <- as.Date('2007-9-14') - as.Date('1953-3-10')
> units(x) <- "epiyears"
>
> which would give you the age in years for those purposes where you don't
> care missing the exact birthday by a day or so.)"
>
>As I said, division is a hard case with no clear answer. The creation of
> other unit schemes is silly --- why in the world would I voluntarily put on
> a straightjacket?
>
We'll put it on for you...
It makes sense to calculate half a difftime or a 12th or a 100th of a
difftime. You were asking the system to magically conclude that a
365.25th of a difftime has a different meaning, a units conversion. This
is the sort of thing that humans can discern, but not machines. The
design is that you change units by using units(x)<-. Unfortunately the
largest regular unit is "weeks", hence the suggestion of "epiyears".
> d.
>
>>> as.Date('09Sep2007')
>>>
>>>
>> Error in fromchar(x) : character string is not in a standard unambiguous
>>
> format
>
> My off-the-cuff suggestion is to make the message honest
> Error in fromchar(x): program is not able to divine the correct format
>
Heh. Pretty close. Now what is a suitable eufemism for "divine"?
> The problem is not that the format is necessarily wrong or ambiguous, but that
> the program can't guess. (Which is no real fault of the program - such
> a recognition is a hard problem. It's ok to ask me for a format string).
>
> --
> Hadley Wickham
> "Why not just always use seconds for difftime objects? An attribute
> could control how it was formatted, but would be independent of the
> underlying representation."
>
> This misses the point.
>
No. It _is_ the point. The design is that the numeric value of a
difftime is nonsensical without knowing the units. This might be
different, although as Brian indicated, the choice is deliberate, and
some deep thinking was involved.
> ---
>
> Gabor Grothendieck
>
> as.Date(10)
> You can define as.Date.numeric in your package and then it will work. zoo
> has done that.
>
> library(zoo)
> as.Date(10)
>
> This is also a nice idea. Although adding to a package is possible, it is
> now very hard to take away, given namespaces. That is, I can't define my
> own Math.Date to do away with the creation of timespan objects. Am I
> correct? Is it also true that adding methods is hard if one uses version 4
> classes?
>
> The rest of Gabor's comments are workarounds for the problem I raised.
> But I don't want to have to wrap "as.numeric" around all of my date
> calculations.
>
>
Just get used to it, I'd say.
> ---
> Brian Ripley
>
> "It fails by design. Using sqrt() on a measurement that has an arbitrary
> origin would not have been good design."
>
> Ah, the classic Unix response of "that's not a bug, it's a feature".
>
> What is interesting is that this is almost precisely the response I
> got when I first argued for a global na.action default. John C (I think)
> replied that, essentially, S SHOULD slap you alonside the head when
> there were missing values. They require careful thought wrt good analysis,
> and allowing a global option was bad design because it would encourage bad
> statistics. The Insightful side of the debate said they didn't dare because
> is might break something. After getting nowhere with talking I finally
> gave up and wrote my own version into the survival code. This leverage
> eventually forced adoption of the idea.
>Not many (any?) people currently set na.action=na.fail because it is
> a "better design".
> --
>
> Historically, languages designed for other people to use have been bad: Cobol,
> PL/I, Pascal, Ada, C++. The good languages have been those that were designed
> for their own creat
Re: [Rd] *.Rd file: space after topic in "\alias{topic }" should be (PR#9915)
On Mon, 17 Sep 2007 [EMAIL PROTECTED] wrote:
> Full_Name: Bill Dunlap
> Version: R version 2.6.0 Under development (unstable) (2007-07-26 r42329)
> OS: Linux
> Submission from: (NULL) (24.16.101.199)
>
> If a *.Rd file has an \alias{topic } with a space
> between 'topic' and the closing '}' then the space
> is copied to the help/AnIndex file and help(topic)
> fails to find the help file.
>
> E.g., if the help file starts with
>\name{test1}
>\alias{test1 }
>\alias{test2}
>\alias{test3 }
>\alias{test4}
> then help(test1) and help(test4) work, but not
> help(test1) or help(test3).
>
> A possible fix is
> --- share/perl/R/Rdlists.pm (revision 42846)
> +++ share/perl/R/Rdlists.pm (working copy)
> @@ -329,7 +329,7 @@
> $main::title2file{$rdtitle} = $manfilebase;
> }
>
> - while($text =~ s/\\alias\{\s*(.*)\s*\}//){
> + while($text =~ s/\\alias\{\s*([^\s]*)\s*\}//){
> $alias = $1;
> $alias =~ s/\\%/%/g;
> if ($internal){
It looks like internal spaces are used in \alias entries,
e.g.,
./R.utils/man/Non-documented_objects.Rd:\alias{Non-documented objects}
./SparseM/man/character-null-class.Rd:\alias{character or NULL-class}
I think the trailing spaces are intended to be ignored,
so a better fix would be
--- Rdlists.pm (revision 42846)
+++ Rdlists.pm (working copy)
@@ -332,6 +332,7 @@
while($text =~ s/\\alias\{\s*(.*)\s*\}//){
$alias = $1;
$alias =~ s/\\%/%/g;
+ $alias =~ s/\s*$//;
if ($internal){
$internal{$alias} = 1;
}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] *.Rd file: space after topic in "\alias{topic }" should be ignored (PR#9914)
Full_Name: Bill Dunlap
Version: R version 2.6.0 Under development (unstable) (2007-07-26 r42329)
OS: Linux
Submission from: (NULL) (24.16.101.199)
If a *.Rd file has an \alias{topic } with a space
between 'topic' and the closing '}' then the space
is copied to the help/AnIndex file and help(topic)
fails to find the help file.
E.g., if the help file starts with
\name{test1}
\alias{test1 }
\alias{test2}
\alias{test3 }
\alias{test4}
then help(test1) and help(test4) work, but not
help(test1) or help(test3).
A possible fix is
--- share/perl/R/Rdlists.pm (revision 42846)
+++ share/perl/R/Rdlists.pm (working copy)
@@ -329,7 +329,7 @@
$main::title2file{$rdtitle} = $manfilebase;
}
- while($text =~ s/\\alias\{\s*(.*)\s*\}//){
+ while($text =~ s/\\alias\{\s*([^\s]*)\s*\}//){
$alias = $1;
$alias =~ s/\\%/%/g;
if ($internal){
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.6.0 for Windows, semi-transparent colours and layout()
On Sat, 15 Sep 2007, Henric Nilsson (Public) wrote: > Hi, > > The added support for semi-transparent colours in `windows' under > R-2.6.0 for Windows is much appreciated. > > However, I've discovered that issuing a `layout' (or `par' with > arguments `mfcol'/`mfrow') call and then trying to plot several figures > with semi-transparent colour on the same page results in only the first > one being fully drawn. E.g. That's not the whole story, as my test examples using multiple subplots did work. The problem I found is that clipping rectangles were being used in some places where I cannot find documentation that they should be. So explicitly setting the clipping rectangle before each alpha-blending call seems to fix the problematic examples, including yours. > > > x <- rnorm(1) > > y <- rnorm(1) > > > > layout(matrix(1:2, ncol = 2)) > > plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) > > plot(y ~ x, pch = 16, col = rgb(1, 0, 0, 0.15)) > > results in the second one having only the axes and box, but no data > points. This is under > > > sessionInfo() > R version 2.6.0 alpha (2007-09-14 r42843) > i386-pc-mingw32 > > locale: > LC_COLLATE=Swedish_Sweden.1252;LC_CTYPE=Swedish_Sweden.1252;LC_MONETARY=Swedish_Sweden.1252;LC_NUMERIC=C;LC_TIME=Swedish_Sweden.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > > Henric > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9896) read.spss converts string variables with
The problem here is that the values in the data do not have trailing
blanks, and the corresponding values in the label table do. That's an
issue about the specific SPSS file, not mentioned in this report.
Take a look at the data read with use.value.labels=FALSE:
> read.spss("problem_file.sav", use.value.labels=FALSE)$CNT
[1] "CZE" "CZE" "CZE" "CZE" "CZE" "CZE" "CZE" "CZE" "CZE" "CZE"
attr(,"value.labels")
United StatesUruguay Turkey
"USA " "URY " "TUR "
Tunisia Thailand Chinese Taipei
"TUN " "THA " "TAP "
Sweden Slovenia Slovak Republic
"SWE " "SVN " "SVK "
...
There is another example of this in the test suite:
> electric<-read.spss("electric.sav",TRUE,TRUE)
> summary(electric)
...
WT58 DAYOFWK VITAL10FAMHXCVRCHD
Min. :123.0 MISSING :130 ALIVE:179 NO : 0 Min. :0.0
1st Qu.:156.0 SUNDAY : 19 DEAD : 61 YES : 0 1st Qu.:0.0
Median :171.0 TUESDAY : 19 NA's:240 Median :0.5
Mean :173.4 WEDNSDAY: 17 Mean :0.5
3rd Qu.:187.0 SATURDAY: 16 3rd Qu.:1.0
Max. :278.0 THURSDAY: 15 Max. :1.0
(Other) : 24
where the label.table attribute has
Browse[1]> vl[[12]]
YES NO
"Y " "N "
but the values are "Y" or "N". And it has been that way since at least R
1.6.2.
I think this has to be a case unanticipated by the original author of
read.spss, and needs to be covered by a new argument to read.spss, since
presumably trimming when matching might not always be required.
On Wed, 5 Sep 2007, Prof Brian Ripley wrote:
> Thank you.
>
> If anyone wants to work on a patch I've put the unencoded files from my
> direct copy at
>
> http://www.stats.ox.ac.uk/pub/bdr/problem_file.sav
> http://www.stats.ox.ac.uk/pub/bdr/problem_file_read.RData
>
> I am afraid I won't have a chance to take a look for at least a couple of
> weeks.
>
>
> On Wed, 5 Sep 2007, [EMAIL PROTECTED] wrote:
>
>> --=_20070905112441_38848
>> Content-Type: text/plain; charset="iso-8859-2"
>> Content-Transfer-Encoding: 8bit
>>
>> I am sending two files attached. The file problem_file.sav was saved in
>> SPSS 10.0. It contains variables of various types, with and without
>> labeling etc., so that you can make experiments.
>>
>> The file problem_file_read.RData was saved in R 2.5.1 (foreign library
>> version 0.8-20). It contains two data frames Schools and Schools2. The
>> former is result of
>> read.spss("problem_file.sav",to.data.frame=TRUE,use.value.labels=TRUE),
>> the latter differs in use.value.lables=FALSE only. As you can see, in the
>> first case read.spss has not read values of string labeled variables at
>> all.
>>
>> I use WinXP.
>>
>> Thank you for your work!
>>
>> Jan Hucin
>>
>> ---
>> Reference: <[EMAIL PROTECTED]>
>>
>> There is nothing we can do to reproduce this without an example 'some.sav'
>> file exhibiting the problem. Can you please supply one?
>>
>> On Mon, 3 Sep 2007, [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: Jan Hucin
>>> Version: 2.5.1 (foreign 0.8-20)
>>> OS: WinXP
>>> Submission from: (NULL) (195.113.83.7)
>>>
>>>
>>> When reading an SPSS file:
>>>
>>> - containing some variable of type String
>>> - with value labels at that variable
>>> - and with determination which values of that variable are considered to
>>> be
>>> missing,
>>>
>>> I have always get where digits were in the original SPSS file.
>>>
>>> Example:
>>> Let's have in an SPSS file "some.sav" the variable A. The type of the
>> variable
>>> is String of length 1.
>>> Let's have a value labeling: 1 = Yes, 2 = No, 8 = Invalid, 9 = Missing.
>>> Let's determine that value 9 is considered to be missing.
>>> When this file is read by
>> abc=read.spss("some.sav",use.value.labels=TRUE), we
>>> get in abc$A on places where "1", "2" etc. were. Surprisingly, we
>> get "N/A"
>>> (not !) on the place where the string "N/A" is.
>>>
>>> If we specify use.value.labels=FALSE, then we get string values (such as
>> "1",
>>> "2") but we lose value labels (Yes, No etc.).
>>>
>>> Let me add that if the variable in the original SPSS file was of type
>> Numeric
>>> (not String), there would be no problem.
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
Re: [Rd] Call C code from R
1) You include libraries just like you would always do. Here is the
example from my package that uses external libraries of ImageMagick and
GTK, standard libraries (stdio, pthread) and R libraries:
#include
#include
#include
#include
#include
#include
#include
#ifndef WIN32
# include
#endif
/* These are to use GTK */
#ifdef USE_GTK
# include
# ifdef WIN32
typedef unsigned long ulong;
# include
# else
# include
# endif
#endif
2) The above is C code and no namespaces are used, however the piece
below is C++ code using namespaces and STL. With C++ you only need to
make sure that you export your function as C: extern "C" {}:
#include
#include
#include
#include
#include
#include
/* list of STL, C++ */
#include
#define BG 0.0
struct TheSeed {
int index, seed;
};
typedef std::list IntList;
typedef std::list SeedList;
Oleg
On Mon, 2007-09-17 at 09:14 +0700, Ольга К. Камнева wrote:
> Hello, All!
>
> I'm new for R-devel list. And I'd like to ask some questions,
> maybe they will be stuped for the most part of members of the
> list.
> I need to call function which is written in C++ from R.
> My questions are:
> 1. How should I include libraries (for example, iomanip,
> sstream, iostream)?
> 2. Can I use namespace?
>
> Thanks All :)
> Olga
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Call C code from R
On Mon, 17 Sep 2007, ? ?. ??? wrote: > Hello, All! > > I'm new for R-devel list. And I'd like to ask some questions, > maybe they will be stuped for the most part of members of the > list. > I need to call function which is written in C++ from R. Your subject line says C > My questions are: > 1. How should I include libraries (for example, iomanip, > sstream, iostream)? > 2. Can I use namespace? What you link into R is a shared object aka DLL. If you use the documented ways (e.g. R CMD CHLIB) to make this, it will be linked against the platform's standard C++ libraries. There are lots of examples of C++ code in CRAN packages doing this. The use of iostream is discussed in 'Writing R Extensions'. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
