Re: [Rd] manipulating the Date & Time classes
Firstly, don't double post. On Tue, Feb 8, 2011 at 2:24 PM, Mike Williamson wrote: > Hello, > > This is mostly to developers, but in case I missed something in my > literature search, I am sending this to the broader audience. > > > - Are there any plans in the works to make "time" classes a bit more > friendly to the rest of the "R" world? I am not suggesting to allow for > fancy functions to manipulate times, per se, or to figure out how to > properly "add" times or anything complicated. Just some fixes to make it > easier to work with the "time" classes. Here is a sampling of some strange > bugs with the time classes that, to my knowledge, don't exist with any other > core classes: > 1. you cannot "unlist" a time without losing the class. E.g., if you > unlist "2010-12-14 20:25:40" (POSIXct), you get "1292387141", at > least on my > OS & with my time zone. Regardless of the exact number, unlisting a time > class converts it to a numeric. You didn't say what your OS is, but two things spring to mind. Why are you calling 'unlist' on an object that isn't a list and ... "it works for me": > unlist(Sys.time()) [1] "2011-02-08 14:46:24.262146 CST" > - upon converting to a numeric, it seems there is an underlying, > assumed origin of "1970-01-01 00:00:00". However, this same > assumption does > not underlie the conversion *back* to a POSIX time, e.g., through > as.POSIXct() function. Therefore, whenever a time is "accidentally" > converted to a numeric, I have to force it back to a time through > as.POSIXct(), *providing my own details* as to the origin. There > is no easy way to find the underlying origin. This makes me > nervous for any > persistent functions I create. If the underlying origin ever > changes, then > all this code will be inaccurate. Maybe the origin will > never change, but > regardless it makes more sense to allow for the same underlying origin > default for "as.POSIXct" that is used when unlisting, or > similar activities > that force the time into a numeric. If it is just numeric, it shouldn't have any attribute and since the origin isn't global, you're sort of stuck. You can keep track of it yourself, or just leave it as the standard unix epoch. > 2. you cannot perform functions that otherwise seem trivial, such > as a "max" or "min". I understand why, for instance, adding is > hard. But > what about max or min? Greater than or less than are possible, as is > order(). I have my own simple scripts using these 2 functions > in order to > create a "max" & "min" for times, but it would be nice to have something > vetted & official. > > min(Sys.time()+1:10) [1] "2011-02-08 14:59:26.40236 CST" > max(Sys.time()+1:10) [1] "2011-02-08 14:59:36.762224 CST" Again, works for me. R.version _ platform x86_64-apple-darwin10.2.0 arch x86_64 os darwin10.2.0 system x86_64, darwin10.2.0 status major 2 minor 12.0 year 2010 month 10 day15 svn rev53317 language R version.string R version 2.12.0 (2010-10-15) > > If others could chime in with any strange behaviors they've seen in > working with times, maybe we could get a critical mass of issues that are > worthy of an overhaul. > > Thanks & Regards, > Mike > > > "Telescopes and bathyscaphes and sonar probes of Scottish lakes, > Tacoma Narrows bridge collapse explained with abstract phase-space maps, > Some x-ray slides, a music score, Minard's Napoleanic war: > The most exciting frontier is charting what's already here." > -- xkcd > > -- > Help protect Wikipedia. Donate now: > http://wikimediafoundation.org/wiki/Support_Wikipedia/en > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
I think for teaching, you need to use R itself. Everything else is going to be a derivative from that, and if you are looking for 'correctness' or 'consistency' with the spirit of R, you can only be disappointed - as everyone will take liberties or bring personal style into the equation. In addition, your points are debatable in terms of priority/value. e.g. what is wrong with 'return'? Certainly provides clarity and consistency if you have if-else constructs. We've all learned from reading R sources, and it seems to have worked out well for many of us. Jeff On Tue, Feb 15, 2011 at 12:04 PM, Paul Johnson wrote: > Hello, > > I am looking for CRAN packages that don't teach bad habits. Can I > have suggestions? > > I don't mean the recommended packages that come with R, I mean the > contributed ones. I've been sampling a lot of examples and am > surprised that many ignore seemingly agreed-upon principles of R > coding. In r-devel, almost everyone seems to support the "functional > programming" theme in Chambers's book on Software For Data Analysis, > but when I go look at randomly selected packages, programmers don't > follow that advice. > > In particular: > > 1. Functions must avoid "mystery variables from nowhere." > > Consider a function's code, it should not be necessary to say "what's > variable X?" and go hunting in the commands that lead up to the > function call. If X is used in the function, it should be in a named > argument, or extracted from one of the named arguments. People who > rely on variables floating around in the user's environment are > creating hard-to-find bugs. > > 2. We don't want functions with indirect effects (no <<- ), almost always. > > 3. Code should be vectorized where possible, C style for loops over > vector members should be avoided. > > 4. We don't want gratuitous use of "return" at the end of functions. > Why do people still do that? > > 5. Neatness counts. Code should look nice! Check out how beautiful > the functions in MASS look! I want code with spaces and " <- " rather > than everything jammed together with "=". > > I don't mean to criticize any particular person's code in raising this > point. For teaching exemples, where to focus? > > Here's one candidate I've found: > > MNP. as far as I can tell, it meets the first 4 requirements. And it > has some very clear C code with it as well. I'm only hesitant there > because I'm not entirely sure that a package's C code should introduce > its own functions for handling vectors and matrices, when some general > purpose library might be more desirable. But that's a small point, > and clarity and completeness counts a great deal in my opinion. > > > > > > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
f3 <- function() {
( a <- 5 )
}
f4 <- function() {
a <- 5
a
}
On my machine f1,f2, and f4 all perform approx. the same. The () in
f3 adds about 20% overhead.
Jeff
On Tue, Feb 15, 2011 at 4:22 PM, Kevin Wright wrote:
> For those of you "familiar with R", here's a little quiz. What what's the
> difference between:
>
>
> f1 <- function(){
> a=5
> }
> f1()
>
> f2 <- function(){
> return(a=5)
> }
> f2()
>
>
> Kevin Wright
>
>
>
>
> On Tue, Feb 15, 2011 at 3:55 PM, Geoff Jentry wrote:
>
>> On Wed, 16 Feb 2011, David Scott wrote:
>>
>>> 4. We don't want gratuitous use of "return" at the end of functions.
>>>> Why do people still do that?
>>>>
>>> Well I for one (and Jeff as well it seems) think it is good programming
>>> practice. It makes explicit what is being returned eliminating the
>>> possibility of mistakes and provides clarity for anyone reading the code.
>>>
>>
>> You're unnecessarily adding the overhead of a function call by explicitly
>> calling return().
>>
>> Sure it seems odd for someone coming from the C/C++/Java/etc world, but
>> anyone familiar with R should find code that doesn't have an explicit
>> return() call to be fully readable & clear.
>>
>> -J
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function call overhead
Hi Paul,
> `:::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
and
> `::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
if (is.null(ns)) {
pos <- match(paste("package", pkg, sep = ":"), search(),
0L)
if (pos == 0)
stop(gettextf("package %s has no name space and is not on
the search path"),
sQuote(pkg), domain = NA)
get(name, pos = pos, inherits = FALSE)
}
else getExportedValue(pkg, name)
}
are the reasons I think.
Jeff
On Wed, Feb 16, 2011 at 12:13 PM, Paul Gilbert
wrote:
> (subject changed from: RE: [Rd] Avoiding name clashes: opinion on best
> practice naming conventions)
>
> Dominick
>
> Is this really true? Is there a speed advantage to defining a local function
> this way, say, within another function, and then calling it within a loop
> rather than the original? Do you have data on this?
>
> Paul
>
>> -Original Message-
>> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
>> project.org] On Behalf Of Dominick Samperi
>> Sent: February 16, 2011 12:44 PM
> ...
>> Since the resolution of myPkg::foo() occurs at runtime (via a function
>> call) instead
>> of at compile time (as it would in C++), this practice can introduce a
>> significant
>> performance hit. This can be avoided by doing something like:
>> mylocalfunc <- myPkg::foo
>> [tight loop that uses mylocalfunc repeatedly]
>>
>> Here mylocalfunc would not be exported, of course.
>>
>> Dominick
> ...
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential information, and the
> Bank of
> Canada does not waive any related rights. Any distribution, use, or copying
> of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it
> immediately from
> your system and notify the sender promptly by email that you have done so.
>
>
>
> Le présent courriel peut contenir de l'information privilégiée ou
> confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
> diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par
> une
> personne autre que le ou les destinataires désignés est interdite. Si vous
> recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
> délai à
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
> votre
> ordinateur toute copie du courriel reçu.
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hook for when R quits
Take a look at reg.finalizer. You'd have to create an object internally that would persist until R exits - and a related function to handle cleanup of course. HTH Jeff On Fri, Mar 11, 2011 at 12:08 PM, Michael Lawrence wrote: > Hi, > > Is there any way that a package can listen for when R quits? The Qt stuff is > hooking into platform-specific event loops and when those die unexpectedly > (from the perspective of Qt), it aborts, causing an annoying error dialog. > If we could catch when R is killed, we could cleanup, like we do with > .onUnload. > > Thanks, > Michael > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help.request() for packages?
For what it is worth, I too would like to see something regarding a "Support" field in the description. One issue with a single maintainer email is that it does make it difficult to assure that questions get properly routed/answered given projects that have multiple contributors or an active community behind them. I would think even hinting to the best R-SIG list would be useful (in my case I typically only follow R-SIG-Finance closely and miss some questions that go to R-help) At the very least, it would make it more obvious to users where they should send general questions about a package. Best, Jeff On Tue, Apr 26, 2011 at 3:08 PM, Matthew Dowle wrote: > Hi, > > Have I missed something, or misunderstood? > > The r-help posting guide asks users to contact the package maintainer : > > "If the question relates to a contributed package, e.g., one > downloaded from CRAN, try contacting the package maintainer first. > [snip] ONLY [only is bold font] send such questions to R-help or R-devel > if you get no reply or need further assistance. This applies to both > requests for help and to bug reports." > > but the R-ext guide contains : > > "The mandatory Maintainer field should give a single name with a > valid (RFC 2822) email address in angle brackets (for sending bug > reports etc.). It should not end in a period or comma. For a public > package it should be a person, not a mailing list and not a corporate > entity: do ensure that it is valid and will remain valid for the > lifetime of the package." > > Currently, data.table contains the datatable-help mailing list in the > 'Maintainer' field, with the posting guide in mind (and service levels > for users). This mailing list is where we would like users to ask > questions about the package, not r-help, and not a single person. > However, R-exts says that the 'Maintainer' email address should not be a > mailing list. > > There seems to be two requirements: > i) a non-bouncing email address that CRAN maintainers can use - more > like the 'Administrator' of the package > ii) a support address for users to send questions and bug reports > > The BugReports field in DESCRIPTION is for bugs only, and allows only a > URL, not an email address. bug.reports() has a 'package' argument and > emails the Maintainer field if the BugReports URL is not provided by the > package. So, BugReports seems close, but not quite what we'd like. > > help.request() appears to have no package argument (I checked R 2.13.0). > > Could a "Support" field (or better name) be added to DESCRIPTION, and a > 'package' argument added to help.request() which uses it? Then the > semantics of the Maintainer field can be closer to what the CRAN > maintainers seem to think of it; i.e., the package 'Administrator'. > > Have I misunderstood or missed an option? > > Matthew > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com R/Finance 2011 April 29th and 30th in Chicago | www.RinFinance.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Wed, Jun 8, 2011 at 7:17 PM, oliver wrote:
> On Wed, Jun 08, 2011 at 02:23:29PM -0400, Simon Urbanek wrote:
> >
> > On Jun 8, 2011, at 12:08 PM, oliver wrote:
> >
> > > On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
> > >> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
> > >>
> > >>> On 07/06/2011 9:08 AM, oliver wrote:
> > >>>> Hello,
> > >>>>
> > >>>> following an advice here from the list I looked into sources of
> other
> > >>>> packages (xts) and found the TYPEOF() macro/function, which really
> is
> > >>>> helpful.
> > >>
> > >> It is documented, of course, but actually better alternatives are
> > >> described in 'Writing R Extensions'.
> > >>
> > >> We would urge you to study the R sources rather than copy bad habits
> > >> from randomly chosen package sources.
> > > [...]
> > >
> > > Hmhh, it was not randomly chosen, it was, what I got as a hint here on
> the list.
> > >
> >
> > It was not provided to you to look at how it checks arguments. For basic
> > usage it's better to look at the R code. The coding styles vary a lot in
> > packages (and so does the quality of packages) - some of them are really
> bad,
> > but you have to remember that most people write packages in their free
> time and
> > are not programmers...
>
> OK, I see.
>
Of course - most of R core aren't "programmers" either - whatever that
means. Statisticians, mathematicians, etc...
;-)
Most contributed packages aren't meant to be case studies in a comp-sci
class either, they are meant to solve real world problems - problems that
many of us work on daily.
That said, I'd also say look to R sources first, but since many things in R
core aren't available in the API - you aren't really able to copy the 'best
practices' alluded to. And sometimes you've got to bootstrap solutions when
the list is otherwise silent. Another reason that you should look outside
of R sources in addition to inside of them is that the community code is far
more abundant that the core code. Sort of like theory vs. practice - they
only teach so much in school.
For reference, TYPEOF is straight from R source (of course):
http://svn.r-project.org/R/trunk/src/main/subset.c
Cheers,
Jeff
>
>
> [...]
> > >> and there is no
> > >> check in that code that LENGTH(filename_sexp) > 0 (or == 1). In the
> > >> R sources you will often see things like
> > >>
> > >>if(!isString(sfile) || LENGTH(sfile) < 1)
> > >>error("invalid '%s' argument", "description");
> > > [...]
> > >
> > > If it's a vector, I can just pic the first element.
> >
> > Yes, but only if it's not a vector of length zero - hence the necessary
> check.
> >
> >
> > > Or does LENGTH(sfile) give the length of the string itself
> > > (like strlen(3))?
> > >
> >
> > No.
> [...]
>
> OK, I looked at this now.
>
> LENGTH() checks the length of the vector.
>
> Good to know this.
>
> So the problem of a vector of length 0 can be with any arguments of type
> SEXP,
> hence I will need to check ANY arg on it's length.
>
> This is vital to stability under any situation.
>
> Thanks for this valuable hint!
>
> I will add checks for all my SEXP-args.
>
>
> Ciao,
> Oliver
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN mirror size mushrooming; consider archiving some?
Or one could buy an iPod and host it from there ;-) 160 GB for US$250. Uwe's plan is probably better though... Jeff On Tue, Jul 26, 2011 at 5:08 PM, Hadley Wickham wrote: > >> I'm setting up a new CRAN mirror and filled up the disk space the > >> server allotted me. I asked for more, then filled that up. Now the > >> system administrators want me to buy an $800 fiber channel card and a > >> storage device. I'm going to do that, but it does make want to > >> suggest to you that this is a problem. > > > > Why? Just for the mirror? That's nonsense. A 6 year old outdated desktop > > machine (say upgraded to 2GB RAM) with a 1T harddisc for 50$ should be > fine > > for your first tries. The bottleneck will probably be your network > > connection rather than the storage. > > Another perspective is that it costs ~$10 / month to store 68 Gb of > data on amazon's S3. And then you pay 12c / GB for download. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slightly speeding up readChar()
Michael, The mmap package currently provides an Ops method for comparisons, which returns something like which(i==) does in R - since a vector of logicals the same size would be likely too big to handle in many cases. At some point I'll implement mmap to mmap operations, though for vectorized ops that result in non-logical output (i.e. numeric), I haven't yet decided on how that should be implemented. Something like a results buffer on disk/memory has been my thinking, but anyone with additional (better!) suggestions please feel free to send me ideas off list. I'll look to add some basic summary statistics as well. Note that you need to have a binary representation on disk (via fwrite in C, or writeBin or as.mmap in R) for this to work. But the package currently supports something like 16 data types, including bit logicals, fixed width character strings (\0 delim vectors), floats (4 byte), and 64 bit ints. The vignette covers a lot of the details. Additionally if you have struct-style data (think row-oriented, with varying types), you can use the struct() feature. This maps to an R list, but allows for very fast access if you are pulling complete rows. example(mmap) example(types) example(struct) The R-forge version has more than the CRAN version at this moment, but I'll be pushing a new one to CRAN soon. Jeff On Fri, Aug 5, 2011 at 8:22 AM, Michael Lachmann wrote: > > On 5 Aug 2011, at 1:20AM, Dirk Eddelbuettel wrote: > > > When you know the (fixed) structure of the data, the CRAN package mmap > can be > > a huge winner. > > Thanks! I didn't know that. > > Is there a package that provides methods for mmap, like sum(x) or maybe > even y=x+z > where x, and z are mmaps? > > I assume that once you mmap to a huge file, you do operations on it by > working on chunks at a time... are there packages for that, or do I have to > write my own code? > > Thanks! > > Michael > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Non-GPL C (or R) inside of a package
R-devel,
I am interested in creating a package that requires non-GPL'd (commercial) C
code to work. In essence it is a single .c file with no use of R headers
(all .C callable functions). For example's sake:
1 #include
2
3 void test (int *a) {
4 *a = 101;
5 }
The package isn't destined for CRAN, and I realize that this isn't R-legal,
but looking for some expert advice from anyone else who may have encountered
this previously.
The question is whether or not one can distribute code that has multiple
licenses (.c or individual .R files), including some that are not
GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
process [R CMD ***] cause everything to become GPL, as we are using R itself
to build the package?
I can of course provide the C libs in this case as a separate install, but
that adds complexity to the overall build and install process.
Thanks,
Jeff
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On Tue, Aug 30, 2011 at 3:52 PM, Prof Brian Ripley
wrote:
>
> On Tue, 30 Aug 2011, Duncan Murdoch wrote:
>
>> On 30/08/2011 1:50 PM, Jeffrey Ryan wrote:
>>>
>>> R-devel,
>>>
>>> I am interested in creating a package that requires non-GPL'd (commercial)
>>> C code to work. In essence it is a single .c file with no use of R headers
>>> (all .C callable functions). For example's sake:
>>>
>>> 1 #include
>>> 2
>>> 3 void test (int *a) {
>>> 4 *a = 101;
>>> 5 }
>>>
>>> The package isn't destined for CRAN, and I realize that this isn't R-legal,
>>> but looking for some expert advice from anyone else who may have
>>> encountered this previously.
>>>
>>> The question is whether or not one can distribute code that has multiple
>>> licenses (.c or individual .R files), including some that are not
>>> GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
>>> process [R CMD ***] cause everything to become GPL, as we are using R
>>> itself to build the package?
>>>
>> I can only say that the answer to the last question is "no": the author
>> gets to choose the license for what s/he wrote. The fact that you used R to
>> package it is irrelevant. (Some extremists will disagree, and say that
>> because your package is intended to "link" to R, it must be licensed
>> compatibly with the GPL if you distribute it. I don't think that's true.)
>
> If no distribution is involved, the conditions under which the tarball can be
> distributed is not relevant.
>
> As e.g. GNU tar is itself under GPL, using R to do the packaging is no
> different in principle to using GNU tar to do so and I've never heard anyone
> argue that using GNU tar affects the licence of the tarball.
Good point. Thanks.
>
> I don't think that is the same issue as distributing non-GPLed code for use
> with R. In the latter case the issue is what 'link to' actually entails, and
> one source of advice is the GPL FAQs. E.g.
> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
> http://www.gnu.org/licenses/gpl-faq.html
I do think this is the same issue. The key part of that rather
wandering FAQ to me is:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
Which states:
"Another similar and very common case is to provide libraries with the
interpreter which are themselves interpreted. For instance, Perl comes
with many Perl modules, and a Java implementation comes with many Java
classes. These libraries and the programs that call them are always
dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java
classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on."
In my own terms, this seems to say using *ANY* GPL code in your
program - even if interpretted at some later point - forces all code
to be GPLed. e.g. A script that creates a simple vector using
something like "v = 1:10" is using the GPLed base package and
therefore must be GPLed itself.
My case is a bit more subtle, as the code that I am writing makes no
use of any GPL code, aside from the compilation and linking to allow
GPL "R" code to access it.
Jeff
>
>> If you are intending to distribute this file you are putting together,
>> you'll probably want to consult someone who knows the legalities as to
>> whether you can legally link to the commercial library...
>
>
>
>>
>> Duncan Murdoch
>>
>>> I can of course provide the C libs in this case as a separate install, but
>>> that adds complexity to the overall build and install process.
>>>
>>> Thanks,
>>> Jeff
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> 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, UK Fax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On Wed, Aug 31, 2011 at 10:40 AM, oliver wrote: > On Wed, Aug 31, 2011 at 10:34:38AM -0500, Jeffrey Ryan wrote: > [...] >> My case is a bit more subtle, as the code that I am writing makes no >> use of any GPL code, aside from the compilation and linking to allow >> GPL "R" code to access it. > [...] > > Just ask people from the FSF, if your issue is complicated. > > Or ask the owner of the nmon-GPLed code, if it is possible > to make it open for your project. > > That does not necessarily mean that the same code in olther > products of the company also needs to become open. > > It's possible to make a "fork". > > You just can't make GPLed code again closed. Right. I understand that perfectly. So likely a tarball with varying licenses *might* be ok, even if all are not GPL compatible - since one file wouldn't affect the other. The final compiled work though would have to be GPLd though, since you couldn't hide the GPLd sections under another license. Seems to make sense to me. And the end-user would have to compile it to have it work, and would need to carry a GPL license... yikes what a mess. I think the external library via an additional download is likely the simplest and safest route all around. Best, Jeff > > > Ciao, > Oliver > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
I would be leery of just taking over as maintainer if a package still works and passes all checks on CRAN. My personal take is that even commercial packages ignore feature requests, and to expect such from an OSS one is expecting too much. Of course patches are welcomed, but they can't honestly be expected to be committed. Even if they are they may be a low priority for the maintainer/author - be it for style, design, or implementation/maintenance purposes. My suggestion would be to continue to ask, but if that doesn't work simply build an extension that others might be able to use with xtable in this case (xtableExtras??). In the absolute last case I would fork it if you feel the need and the intense desire to maintain a whole new version. The caveat of adding another package that duplicates, but only adds one feature (however amazing you think), isn't likely to be helpful to the entire R universe - in fact it is likely harmful. my 2c Jeff On Sat, Sep 10, 2011 at 9:40 AM, Spencer Graves wrote: > > > On 9/10/2011 6:06 AM, Uwe Ligges wrote: >> >> >> On 10.09.2011 13:26, Alastair wrote: >>> >>> Hi, >>> >>> I wonder if anyone knows if the xtable package is still actively being >>> maintained? The last update to the CRAN was about 2 years ago. Earlier in >>> the year I found I wanted to use the short caption option of LaTeX tables >>> to >>> display an abridged title in my table of contents. It was a relatively >>> simple change to get xtable to support this. I bundled up my changes and >>> sent the maintainer David B. Dahl an email and I got absolutely no >>> response? >> >> Try to "ping" - at least I do so in this case. No response would be >> unfortunate, of course. > > > David B. Dahl still has a web site as an Associate Professor at Texas > A&M U. >> >> >>> What's the etiquette for this kind of situation? I think he's done a >>> sterling job maintaining a really useful package; I wanted to help and >>> contribute to the community but if he's not doing it anymore how can >>> anyone >>> get their improvements / bug fixes into circulation? >> >> xtable's DESCRIPTION file says >> >> License: GPL (>= 2) >> >> so go ahead in case you do not get a response. >> >> Best, >> Uwe Ligges > > > xtable has a long list of reverse depends, imports, suggests and > enhances, so many people clearly think it's useful. > > > My preference is to encourage the maintainer(s) to migrate the project > to R-Forge where others can help maintain it and add enhancements (that > shouldn't break current applications) that people feel are generally useful. > (Not everyone responds positively to this kind of suggestion, but some do.) > > > R-Forge also lists tabulaR, which "is a comprehensive package for > presenting quality tabular output within the R Environment. Differing from > xtable and Hmisc, it manipulates, formats and presents tabular data to any R > device stream, which can then be used by any structured format." So far, > however, I was unable to find evidence that the the tabulaR team has done > anything for with R-Forge beyond successfully getting a shell created for > the project. > > > Good luck! > Spencer >> >> >>> >>> Cheers, >>> Alastair >>> >>> -- >>> View this message in context: >>> http://r.789695.n4.nabble.com/Is-xtable-still-being-maintained-tp3803657p3803657.html >>> Sent from the R devel mailing list archive at Nabble.com. >>> >>> __ >>> 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 >> > > > -- > Spencer Graves, PE, PhD > President and Chief Technology Officer > Structure Inspection and Monitoring, Inc. > 751 Emerson Ct. > San José, CA 95126 > ph: 408-655-4567 > web: www.structuremonitoring.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it possible to pass a function argument from R to compiled code in C?
You can't call "R" code as if it is C code. It is R, and requires that it be evaluated. How would your C know what to do with an R pointer... .Call is more efficient than .C, all the time. Check this list and experiment. That said, you can still call "just C" within the .Call "R" function, it really is 'just C' in there. Probably something like a simple example of what you are trying to do would help the list steer you into the right direction (steer, since you seem to be missing something in your thinking on this...) Best, Jeff On Tue, Sep 20, 2011 at 1:07 PM, Alireza Mahani wrote: > OK, thanks. But there are two issues with using ".Call": > > 1- I may give up performance if I am literally running R code inside C, > right? In some ways, wouldn't it defy the purpose of calling a compiled code > if I end up back in R? > > 2- If I use the ".Call" interface, the resulting code will be tailored to R, > i.e. I will end up having the lengthy code with all the R macros in it. I > always prefer to use ".C" interface because I can use the exact same piece > of code inside of a C program, i.e. I can call the same function either from > R or from C. But with .Call, I am passing R's pointers into the function, > which obviously I won't be doing when my call comes from inside of C. > > Nevertheless, it's good to know that there is at least a sub-optimal > solution out there (sub-optimal from my perspective, of course!). > > -Alireza > > -- > View this message in context: > http://r.789695.n4.nabble.com/Is-it-possible-to-pass-a-function-argument-from-R-to-compiled-code-in-C-tp3827563p3827690.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with seek() on gzipped connections in R-devel
seek() in general is a bad idea IMO if you are writing cross-platform code.
?seek
Warning:
Use of ‘seek’ on Windows is discouraged. We have found so many
errors in the Windows implementation of file positioning that
users are advised to use it only at their own risk, and asked not
to waste the R developers' time with bug reports on Windows'
deficiencies.
Aside from making me laugh, the above highlights the core reason to not use IMO.
For not zipped files, you can try the mmap package. ?mmap and ?types
are good starting points. Allows for accessing binary data on disk
with very simple R-like semantics, and is very fast. Not as fast as a
sequential read... but fast. At present this is 'little endian' only
though, but that describes most of the world today.
Best,
Jeff
On Fri, Sep 23, 2011 at 8:58 AM, Jon Clayden wrote:
> Dear all,
>
> In R-devel (2011-09-23 r57050), I'm running into a serious problem
> with seek()ing on connections opened with gzfile(). A warning is
> generated and the file position does not seek to the requested
> location. It doesn't seem to occur all the time - I tried to create a
> small example file to illustrate it, but the problem didn't occur.
> However, it can be seen with a file I use for testing my packages,
> which is available through the URL
> <https://github.com/jonclayden/tractor/blob/master/tests/data/nifti/maskedb0_lia.nii.gz?raw=true>:
>
>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>> seek(con, 352)
> [1] 0
> Warning message:
> In seek.connection(con, 352) :
> seek on a gzfile connection returned an internal error
>> seek(con, NA)
> [1] 190
>
> The same commands with the same file work as expected in R 2.13.1, and
> have worked over many previous versions of R.
>
>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>> seek(con, 352)
> [1] 0
>> seek(con, NA)
> [1] 352
>
> My sessionInfo() output is:
>
> R Under development (unstable) (2011-09-23 r57050)
> Platform: x86_64-apple-darwin11.1.0 (64-bit)
>
> locale:
> [1] en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>
> attached base packages:
> [1] splines stats graphics grDevices utils datasets methods
> [8] base
>
> other attached packages:
> [1] tractor.nt_2.0.1 tractor.session_2.0.3 tractor.utils_2.0.0
> [4] tractor.base_2.0.3 reportr_0.2.0
>
> This seems to occur whether or not R is compiled with
> "--with-system-zlib". I see some zlib-related changes mentioned in the
> NEWS, but I don't see any indication that this is expected. Could
> anyone shed any light on it, please?
>
> Thanks and all the best,
> Jon
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with seek() on gzipped connections in R-devel
Yes, inelegant would be a good description. Sadly a fact we have to
put up with I guess.
FWIW, I too don't like dependencies. mmap has none, and is cross
platform, but I get the idea.
Good luck,
Jeff
On Fri, Sep 23, 2011 at 11:13 AM, Jon Clayden wrote:
> Thanks for the replies. I take the point, although it does seem like a
> substantial regression (on non-Windows platforms).
>
> I like to keep the external dependencies of my packages minimal, but I
> will look into the mmap package - thanks, Jeff, for the tip.
>
> Aside from that, though, what is the alternative to using seek? If I
> want to read something at (original, uncompressed) byte offset 352, as
> here, do I have to read and discard everything that comes before it
> first? That seems inelegant at best...
>
> Regards,
> Jon
>
>
> On 23 September 2011 16:54, Jeffrey Ryan wrote:
>> seek() in general is a bad idea IMO if you are writing cross-platform code.
>>
>> ?seek
>>
>> Warning:
>>
>> Use of ‘seek’ on Windows is discouraged. We have found so many
>> errors in the Windows implementation of file positioning that
>> users are advised to use it only at their own risk, and asked not
>> to waste the R developers' time with bug reports on Windows'
>> deficiencies.
>>
>> Aside from making me laugh, the above highlights the core reason to not use
>> IMO.
>>
>> For not zipped files, you can try the mmap package. ?mmap and ?types
>> are good starting points. Allows for accessing binary data on disk
>> with very simple R-like semantics, and is very fast. Not as fast as a
>> sequential read... but fast. At present this is 'little endian' only
>> though, but that describes most of the world today.
>>
>> Best,
>> Jeff
>>
>> On Fri, Sep 23, 2011 at 8:58 AM, Jon Clayden wrote:
>>> Dear all,
>>>
>>> In R-devel (2011-09-23 r57050), I'm running into a serious problem
>>> with seek()ing on connections opened with gzfile(). A warning is
>>> generated and the file position does not seek to the requested
>>> location. It doesn't seem to occur all the time - I tried to create a
>>> small example file to illustrate it, but the problem didn't occur.
>>> However, it can be seen with a file I use for testing my packages,
>>> which is available through the URL
>>> <https://github.com/jonclayden/tractor/blob/master/tests/data/nifti/maskedb0_lia.nii.gz?raw=true>:
>>>
>>>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>>>> seek(con, 352)
>>> [1] 0
>>> Warning message:
>>> In seek.connection(con, 352) :
>>> seek on a gzfile connection returned an internal error
>>>> seek(con, NA)
>>> [1] 190
>>>
>>> The same commands with the same file work as expected in R 2.13.1, and
>>> have worked over many previous versions of R.
>>>
>>>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>>>> seek(con, 352)
>>> [1] 0
>>>> seek(con, NA)
>>> [1] 352
>>>
>>> My sessionInfo() output is:
>>>
>>> R Under development (unstable) (2011-09-23 r57050)
>>> Platform: x86_64-apple-darwin11.1.0 (64-bit)
>>>
>>> locale:
>>> [1] en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>>
>>> attached base packages:
>>> [1] splines stats graphics grDevices utils datasets methods
>>> [8] base
>>>
>>> other attached packages:
>>> [1] tractor.nt_2.0.1 tractor.session_2.0.3 tractor.utils_2.0.0
>>> [4] tractor.base_2.0.3 reportr_0.2.0
>>>
>>> This seems to occur whether or not R is compiled with
>>> "--with-system-zlib". I see some zlib-related changes mentioned in the
>>> NEWS, but I don't see any indication that this is expected. Could
>>> anyone shed any light on it, please?
>>>
>>> Thanks and all the best,
>>> Jon
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>>
>> --
>> Jeffrey Ryan
>> jeffrey.r...@lemnica.com
>>
>> www.lemnica.com
>> www.esotericR.com
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
I'd second this. Though my thinking was to add writeRDS instead of saveRDS. Jeff On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickham wrote: > Hi all, > > Is there any chance that readRDS and saveRDS might one day become > read.rds and write.rds? That would make them more consistent with the > other reading and writing functions. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
As load involves a side-effect, I would think that loadRDS is a bad idea. That said, read/write is far more consistent across all languages and internally with R than read/save is. My (worthless) vote is for writeRDS. Jeff On Tue, Oct 18, 2011 at 11:37 AM, Hadley Wickham wrote: >>> Is there any chance that readRDS and saveRDS might one day become >>> read.rds and write.rds? That would make them more consistent with the >>> other reading and writing functions. >> >> Ending names in .foo is a bad idea because of the S3 naming conventions, so >> I think this is unlikely. But you can always create an alias yourself... > > It just makes teaching that much harder. We have the pairs: > > * read.csv and write.csv > * load and save > * readRDS and saveRDS > > Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current > combo. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Efficiency of factor objects
Or better still, extend R via the mechanisms in place. Something akin to a fast factor package. Any change to R causes downstream issues in (hundreds of?) millions of lines of deployed code. It almost seems hard to fathom that a package for this doesn't already exist. Have you searched CRAN? Jeff On Sat, Nov 5, 2011 at 11:30 AM, Milan Bouchet-Valat wrote: > Le vendredi 04 novembre 2011 à 19:19 -0400, Stavros Macrakis a écrit : >> R factors are the natural way to represent factors -- and should be >> efficient since they use small integers. But in fact, for many (but >> not all) operations, R factors are considerably slower than integers, >> or even character strings. This appears to be because whenever a >> factor vector is subsetted, the entire levels vector is copied. > Is it so common for a factor to have so many levels? One can probably > argue that, in that case, using a numeric or character vector is > preferred - factors are no longer the "natural way" of representing this > kind of data. > > Adding code to fix a completely theoretical problem is generally not a > good idea. I think you'd have to come up with a real use case to hope > convincing the developers a change is needed. There are probably many > more interesting areas where speedups can be gained than that. > > > Regards > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq.Date bug?
format(ISOdate(2012,1:12,1),"%b-%Y") [1] "Jan-2012" "Feb-2012" "Mar-2012" "Apr-2012" "May-2012" "Jun-2012" [7] "Jul-2012" "Aug-2012" "Sep-2012" "Oct-2012" "Nov-2012" "Dec-2012" First of the month is just as clean, and AFAIR they all have a first ;-) Jeff On Tue, Jan 31, 2012 at 2:37 PM, Dirk Eddelbuettel wrote: > > On 31 January 2012 at 15:17, Duncan Murdoch wrote: > | On 12-01-31 2:56 PM, Dirk Eddelbuettel wrote: > | > > | > R> seq(as.Date(Sys.Date()), by="-1 months", length=6) > | > [1] "2012-01-31" "2011-12-31" "2011-12-01" "2011-10-31" "2011-10-01" > "2011-08-31" > | > R> > | > > | > Notice how October appears twice. > | > | > > | > Now, date arithmetic is gruesome but the documentation for seq.Date et al > | > does not hint it wouldn't honour the by= argument. So a bug, or merely a > | > somewhat less than desirable features. > | > | It is giving you Jan 31, Dec 31, Nov 31, Oct 31, Sep 31, Aug 31 -- > | except some of those months don't have 31 days, so it is converting > | those dates to ones that really exist. (This is documented in ?seq.POSIXt.) > | > | Isn't this what you asked for? > > No as I was feeding this into format(..., "%b-%y") to create 'pretty' names, > and the double entries screw that. > > Morale: pick a mid-month date, and shift that. > > Dirk > > | Duncan Murdoch > | > | > | > > | > (And yes, I think I know that Hadley's lubridate has code for this too, > but > | > so may my RcppBDT which is sitting on top of Boost::DateTime code ...) > | > > | > Dirk > | > > | > > -- > "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too > dark to read." -- Groucho Marx > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] which R package is used for browsing web pages through coding
Probably not R-devel, more likely R-help or google. Why not just use the 6+ solutions you have outlined and use R for what R is good at? Jeff On Fri, Feb 10, 2012 at 4:54 AM, sagarnikam123 wrote: > i know RCurl pakage to retrieve web content,it has limited use, i want > interactive package like > > (in perl--->Mechanize, > In java--->Watij,Prowser,HTMLunit,HTTPunit, > in Ruby>Watir ,etc) > > this modules/packages opens appropriate browser,which can create > queries,retrieves output, clicks buttons, fill up form > automatically,searches keyword in search engine, Downloads many items from > internet > All this is by coding > > if find ,kindly give me sample examples(codes) at list two/five > if not found,give me RCurl's sample codes starting from how to import > library to closing browser, > with explanation for each line of code > > > -- > View this message in context: > http://r.789695.n4.nabble.com/which-R-package-is-used-for-browsing-web-pages-through-coding-tp4375909p4375909.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
Doesn't this also mean that if Matrix is loaded first, det() will be calling Matrix::determinant, which could be quite surprising change in behavior from expectation? This seems rather dangerous and 'untrustworthy' to me - unless I am missing some other hidden mechanism involved here. I haven't read the code yet, and I am sure Matrix will "do the right thing", but I have strong reservations about this behavior when applied to the general universe of R and CRAN. Jeff On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler wrote: >>>>>> Matthew Dowle >>>>>> on Mon, 27 Feb 2012 09:59:43 + writes: > > > Hello, > > > Regarding this in R-devel/NEWS/New features : > > > o 'library(pkg)' no longer warns about a conflict with a > > function from 'package:base' if the function is an > > identical copy of the base one but with a different > > environment. > > > Why would one want an identical copy in a different > > environment? I'm thinking I may be missing out on a trick > > here. > > Yes, you are ;-) The trick is called ``namespace'' : > > One example which lead me to implement the above: > > The Matrix package has had an identical copy of 'det' for a > while now, but of course in the Matrix namespace. > Because of that, the call to determinant() inside det() will > correctly dispatch Matrix methods for determinant(), whereas > base::det() would not. > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
On Mon, Feb 27, 2012 at 9:19 AM, Martin Maechler
wrote:
>>>>>> Jeffrey Ryan
>>>>>> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
>
> > Doesn't this also mean that if Matrix is loaded first,
> > det() will be calling Matrix::determinant, which could be
> > quite surprising change in behavior from expectation?
>
>
> > This seems rather dangerous and 'untrustworthy' to me -
> > unless I am missing some other hidden mechanism involved here.
>
> The only change in R-devel is that library() does not warn about
> *conflicts* in such a case.
Yes, I understand that is only the warning here - but what, aside from
hiding a conflict (which the user may *indeed* care about), does this
accomplish?
To me, a conflict is something to be aware of - hiding it is where I
become concerned.
Without warning, one R script may run differently now depending on
packages loaded, and not just package functions explicitly called by
the script. Without the warning I can envision countless hours
attempting to debug errors - if one is lucky enough to note the change
in behavior.
Behavioral changes can also related to performance. I had seen this
previously with some cbind behavior when the S4 variant from
package:methods overwrote the (much faster) base::cbind by a package
which I will not name (and has since been fixed).
Jeff
> This behavior (and the R code in library()'s checkConflicts())
> is completely analogous to
> importFrom("base", det)
> export(det)
> but as you surely know, we can not (yet?) import from base.
>
> So again: No changed behavior of R, just some warnings less in a
> case where they are typically inappropriate.
>
> > I haven't read the code yet, and I am sure Matrix will "do
> > the right thing", but I have strong reservations about
> > this behavior when applied to the general universe of R
> > and CRAN.
>
> > Jeff
>
> > On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> > wrote:
> >>>>>>> Matthew Dowle on Mon,
> >>>>>>> 27 Feb 2012 09:59:43 + writes:
> >>
> >> > Hello,
> >>
> >> > Regarding this in R-devel/NEWS/New features :
> >>
> >> > o 'library(pkg)' no longer warns about a conflict
> >> with a > function from 'package:base' if the function
> >> is an > identical copy of the base one but with a
> >> different > environment.
> >>
> >> > Why would one want an identical copy in a different
> >> > environment? I'm thinking I may be missing out on a
> >> trick > here.
> >>
> >> Yes, you are ;-) The trick is called ``namespace'' :
> >>
> >> One example which lead me to implement the above:
> >>
> >> The Matrix package has had an identical copy of 'det' for
> >> a while now, but of course in the Matrix namespace.
> >> Because of that, the call to determinant() inside det()
> >> will correctly dispatch Matrix methods for determinant(),
> >> whereas base::det() would not.
> >>
> >> Martin
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > Jeffrey Ryan jeffrey.r...@lemnica.com
>
> > www.lemnica.com www.esotericR.com
>
> > R/Finance 2012: Applied Finance with R www.RinFinance.com
>
> > See you in Chicago
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
Doug, Agreed on the interesting point - looks like it has some real promise. I think the spike in interest could be attributable to Mike Loukides's tweet on Feb 20. (editor at O'Reilly) https://twitter.com/#!/mikeloukides/status/171773229407551488 That is exactly the moment I stumbled upon it. Jeff On Thu, Mar 1, 2012 at 11:06 AM, Douglas Bates wrote: > My purpose in mentioning the Julia language (julialang.org) here is > not to start a flame war. I find it to be a very interesting > development and others who read this list may want to read about it > too. > > It is still very much early days for this language - about the same > stage as R was in 1995 or 1996 when only a few people knew about it - > but Julia holds much potential. There is a thread about "R and > statistical programming" on groups.google.com/group/julia-dev. As > always happens, there is a certain amount of grumbling of the "R IS > S SLW" flavor but there is also some good discussion regarding > features of R (well, S actually) that are central to the language. > (Disclaimer: I am one of the participants discussing the importance of > data frames and formulas in R.) > > If you want to know why Julia has attracted a lot of interest very > recently (like in the last 10 days), as a language it uses multiple > dispatch (like S4 methods) with methods being compiled on the fly > using the LLVM (http://llvm.org) infrastructure. In some ways it > achieves the Holy Grail of languages like R, Matlab, NumPy, ... in > that it combines the speed of compiled languages with the flexibility > of the high-level interpreted language. > > One of the developers, Jeff Bezanson, gave a seminar about the design > of the language at Stanford yesterday, and the video is archived at > http://www.stanford.edu/class/ee380/. You don't see John Chambers on > camera but I am reasonably certain that a couple of the questions and > comments came from him. > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
Is there a distinction as to NOTE vs. WARNING that is documented? I've always assumed (wrongly?) that NOTES weren't an issue with publishing on CRAN, but that they may change to WARNINGS at some point. Is the process by which this happens documented somewhere? Jeff On 3/27/12 11:09 AM, "Gabor Grothendieck" wrote: >2012/3/27 Uwe Ligges : >> >> >> On 27.03.2012 17:09, Gabor Grothendieck wrote: >>> >>> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley >>> wrote: CRAN has for some time had a policies page at http://cran.r-project.org/web/packages/policies.html and we would like to draw this to the attention of package maintainers. In particular, please - always send a submission email to c...@r-project.org with the package name and version on the subject line. Emails sent to individual members of the team will result in delays at best. - run R CMD check --as-cran on the tarball before you submit it. Do this with the latest version of R possible: definitely R 2.14.2, preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are able to give better diagnostics, e.g. for compiled code and especially on Windows. They may also have extra checks for recently uncovered problems.) Also, please note that CRAN has a very heavy workload (186 packages were published last week) and to remain viable needs package maintainers to make its life as easy as possible. >>> >>> Regarding the part about "warnings or significant notes" in that page, >>> its impossible to know which notes are significant and which ones are >>> not significant except by trial and error. >> >> >> >> Right, it needs human inspection to identify false positives. We believe >> most package maintainers are able to see if he or she is hit by such a >>false >> positive. > >The problem is that a note is generated and the note is correct. Its >not a false positive. But that does not tell you whether its >"significant" or not. There is no way to know. One can either try to >remove all notes (which may not be feasible) or just upload it and by >trial and error find out if its accepted or not. > >-- >Statistics & Software Consulting >GKX Group, GKX Associates Inc. >tel: 1-877-GKX-GROUP >email: ggrothendieck at gmail.com > >__ >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] CRAN policies
Thanks Uwe for the clarification on what goes and what stays. Still fuzzy on the notion of "significant" though. Do you have an example or two for the list? Jeff P.S. I meant to also thank all of CRAN volunteers for the momentous efforts involved, and it is nice to see some explanation of how we can help, as well as a peek into what goes on 'behind the curtain' ;-) On 3/27/12 1:19 PM, "Uwe Ligges" wrote: > > >On 27.03.2012 19:10, Jeffrey Ryan wrote: >> Is there a distinction as to NOTE vs. WARNING that is documented? I've >> always assumed (wrongly?) that NOTES weren't an issue with publishing on >> CRAN, but that they may change to WARNINGS at some point. > >We won't kick packages off CRAN for Notes (but we will if Warnings are >not fixed), but we may not accept new submissions with significant Notes. > >Best, >Uwe Ligges > > > >> Is the process by which this happens documented somewhere? >> >> Jeff >> >> On 3/27/12 11:09 AM, "Gabor Grothendieck" >>wrote: >> >>> 2012/3/27 Uwe Ligges: >>>> >>>> >>>> On 27.03.2012 17:09, Gabor Grothendieck wrote: >>>>> >>>>> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley >>>>>wrote: >>>>>> >>>>>> CRAN has for some time had a policies page at >>>>>> http://cran.r-project.org/web/packages/policies.html >>>>>> and we would like to draw this to the attention of package >>>>>> maintainers. >>>>>> In >>>>>> particular, please >>>>>> >>>>>> - always send a submission email to c...@r-project.org with the >>>>>> package >>>>>> name and version on the subject line. Emails sent to individual >>>>>> members >>>>>> of >>>>>> the team will result in delays at best. >>>>>> >>>>>> - run R CMD check --as-cran on the tarball before you submit it. Do >>>>>> this with the latest version of R possible: definitely R 2.14.2, >>>>>> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R >>>>>>are >>>>>> able to give better diagnostics, e.g. for compiled code and >>>>>>especially >>>>>> on Windows. They may also have extra checks for recently uncovered >>>>>> problems.) >>>>>> >>>>>> Also, please note that CRAN has a very heavy workload (186 packages >>>>>> were >>>>>> published last week) and to remain viable needs package maintainers >>>>>>to >>>>>> make >>>>>> its life as easy as possible. >>>>>> >>>>> >>>>> Regarding the part about "warnings or significant notes" in that >>>>>page, >>>>> its impossible to know which notes are significant and which ones are >>>>> not significant except by trial and error. >>>> >>>> >>>> >>>> Right, it needs human inspection to identify false positives. We >>>>believe >>>> most package maintainers are able to see if he or she is hit by such a >>>> false >>>> positive. >>> >>> The problem is that a note is generated and the note is correct. Its >>> not a false positive. But that does not tell you whether its >>> "significant" or not. There is no way to know. One can either try to >>> remove all notes (which may not be feasible) or just upload it and by >>> trial and error find out if its accepted or not. >>> >>> -- >>> Statistics& Software Consulting >>> GKX Group, GKX Associates Inc. >>> tel: 1-877-GKX-GROUP >>> email: ggrothendieck at gmail.com >>> >>> __ >>> 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] Using other peoples packages from within C-based R-extension
This link may be of help as well... https://stat.ethz.ch/pipermail/r-devel/2008-November/051262.html HTH Jeff On 4/24/12 12:35 PM, "oliver" wrote: >Hello, > >OK, thanks for the information... > > >On Tue, Apr 24, 2012 at 12:02:33PM -0500, Dirk Eddelbuettel wrote: >> >> On 24 April 2012 at 12:39, Duncan Murdoch wrote: >> | On 24/04/2012 12:31 PM, oliver wrote: >> | > Hello, >> | > >> | > what if I want to write a package mixed R/C-extension >> | > and want to use code that is provided by other peoples packages? >> | > >> | > How for example can I use one of the provided wavelet packages >> | > from within my C-based R-extension? >> | > >> | > Somehow I would need to load the other packages and have access to >>the >> | > functions they provide. >> | > I mean I don't want to use the other packages via R-level, but >>directly >> | > on the C-layer. Something like shared libs (dlopen and such stuff) >> | > but via R-API. >> | > >> | > Is there a general aproach to this, and how to do it? >> | >> | See "Registering native routines" in the Writing R Extensions manual. >> >> And there are over 120 packages providing access: >> >>CITAN Cubist GOSim KernSmooth MASS MSBVAR Matrix NetComp PMA >>PopGenome >>QuACN RCurl RODBC RTextTools Rcpp Rigroup Rlabkey Rmosek Rmpfr Rook >>Rserve >>Runuran SASxport SMCP SoDA TraMineR XML actuar adaptivetau akima >>aster >>aster2 bcv bda blme boolfun bstats canvas caret catnet cgh chron >>class >>climdex.pcic clpAPI clue cluster copula cplexAPI cplm datamap devEMF >>edesign expm fastICA fastcluster ff flsa foreign fracdiff >>fuzzyRankTests >>gb glpkAPI gmp gputools grpreg gsmoothr heavy hypred ifs ifultools >>int64 >>interactivity kza lattice lfe lme4 locfit lpSolveAPI markdown mgcv >>minqa >>mugnet ncvreg nlme nnet pedigreemm phangorn phmm potts ppstat qtbase >>qtpaint quadprog rPorta randtoolbox rcdd rdyncall rgeos rggobi >>rmongodb >>rngWELL robustbase rpart rphast rrp rtfbs sde sensitivityPStrat sp >>spatial >>spdep spsurvey spt tree tripack uncompress vines xlsReadWrite xts >>yaml zoo >[...] > >But no wavelets stuff... (?) >(It was more than an example, I'm look for wavelet decompositioning.) > > >> >> Matrix and lme4 is the prototypical example by R Core, MASS also >>provides >> something. I'd probably start with zoo and xts ... >[...] > >You mean with "start with" that I could look how to allow exporting >for my own package? > >At the moment I'm rather looking for how to import symbols and access >fnuctionality >of othera people's packages ... > > >Ciao, > Oliver > >__ >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] Capturing signals from within external libs
I have a continuous loop running in an external library that I am calling
from C (R API). This loop is processing events in real time with the
possibility of significant lag between events.
When processing an event, I can make use of R_CheckUserInterrupt, but
while the external library code is waiting on a new event, I don't have an
opportunity to call this - my entry points are only on events.
I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
calling the lib, but I am somewhat at a loss in terms of what I can do
within the handler that would let me pass control back to R.
void myhandler (int s) {
error("interrupt caught!");
}
Works, but I am sure it isn't supposed to. In fact I know it is wrong,
since after interrupting once SIGINTs are subsequently ignored, even if I
reset the signal to the original one (as returned by the first call to
signal).
Currently I can exit(1) of course, but that is tragically bad form IMO,
though will work in my situation.
In short, what is the proper way to handle SIGINT in external code that is
called from R, that allows R to handle the signal. Thoughts or
suggestions appreciated.
Thanks,
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing signals from within external libs
Simon,
Thanks for the clarifying example. I fear my current set up fails the
test for 'no R calls', so I think I am stuck on the ugly variant for my
current challenge, but I will be able to use this in other places.
Thanks again,
Jeff
On 5/22/12 4:45 PM, "Simon Urbanek" wrote:
>Jeff,
>
>On May 22, 2012, at 4:31 PM, Jeffrey Ryan wrote:
>
>> I have a continuous loop running in an external library that I am
>>calling
>> from C (R API). This loop is processing events in real time with the
>> possibility of significant lag between events.
>>
>> When processing an event, I can make use of R_CheckUserInterrupt, but
>> while the external library code is waiting on a new event, I don't have
>>an
>> opportunity to call this - my entry points are only on events.
>>
>
>Assuming that while in the library there are no R calls (important!), you
>can use setjmp/longjmp to branch your code depending on whether you raise
>an interrupt or not (see below). This also makes sure that you process
>things on the R side properly
>
>Another alternative is to run your library call on a separate thread and
>have R wait for the result. In that case you don't need to mess with
>interrupts since your library code will run separately from R. The
>downside is that you need to mess with threads which may or may not be an
>issue depending on the complexity of your code and whether you want it to
>be cross-platform or not.
>
>Cheers,
>Simon
>
>
>Example code:
>
>#include
>#include
>#include
>
>#include
>#include /* only needed if you use
>R_interrupts_pending */
>
>static jmp_buf jenv;
>
>static void my_int(int sig) {
> longjmp(jenv, 1); /* this also restores the interrupt handlers */
>}
>
>SEXP my_R_function(...) {
>
>if (setjmp(jenv) == 0) { /* enter your protected code */
> void (*old_sig)(int);
> old_sig = signal(SIGINT, my_int);
> /* call your library here */
> /* restore original INT handler */
> signal(SIGINT, old_sig);
>} else { /* this will get called on interrupt */
> /* you can do what you want - you're back to R-safe code here, so you
>can either raise an error or return from your function */
> /* if you want to trigger regular R interrupt handling, use this: */
> R_interrupts_pending = 1;
> R_CheckUserInterrupt();
> /* the above should not return */
>}
>
>
>
>> I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
>> calling the lib, but I am somewhat at a loss in terms of what I can do
>> within the handler that would let me pass control back to R.
>>
>> void myhandler (int s) {
>> error("interrupt caught!");
>> }
>>
>> Works, but I am sure it isn't supposed to. In fact I know it is wrong,
>> since after interrupting once SIGINTs are subsequently ignored, even if
>>I
>> reset the signal to the original one (as returned by the first call to
>> signal).
>>
>> Currently I can exit(1) of course, but that is tragically bad form IMO,
>> though will work in my situation.
>>
>> In short, what is the proper way to handle SIGINT in external code that
>>is
>> called from R, that allows R to handle the signal. Thoughts or
>> suggestions appreciated.
>>
>> Thanks,
>> Jeff
>>
>> __
>> 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] Capturing signals from within external libs
Simon,
Very likely butchered my initial problem explanation. The issue is that I
make a call to a library, something like:
SEXP my_fun() {
...
CB = MyCallback("XYZ"); /* this contains callback functions that in turn
use R */
externalLibCall(CB); /* infinite loop that won't return as it is
capturing streaming data */
/* we never get here */
Return(R_NilValue);
}
My callbacks look something like
on_event_A () {
R_CheckUserInterrupt():
evalRFunctionFromC();
}
But event_A only gets called when a new message arrives. When a new
message arrives the on_event_A gets called from within the external
library code (hence calling R), but only when a message arrives.
At this point R_CheckUserInterrupt() works just fine. The problem is when
the external process is waiting on a new message. I have no entry to
check whether or not a message is available, nothing akin to select().
Basically I only get control in my callback when a new message happens.
So if there is no new message (in the context above it is a message/tick
from an exchange), the process spins/waits/not too sure what happens
internally, but the net result is I don't see anything. I am waiting. It
is at this point that I want to force an interrupt.
My current solution is just to redefine as my SIGINT handler before the
externalLibCall call, with an ungraceful exit() internal to it. Dirty,
but lets me break. In the ideal world I would be returned to the R prompt,
but it isn't overly critical in this application since it is being run
more or less headless as is.
The other problem, which makes me cringe of course, is that this is all
further complicated by the fact that it is not just C, but C++ and running
on Win64 ;-) I tried not to mention that of course ...
Your insights are very appreciated, and I now have further knowledge into
making this work in other applications, but my hope for this one is
dwindling.
Best,
Jeff
On 5/23/12 11:49 AM, "Simon Urbanek" wrote:
>
>On May 23, 2012, at 12:40 PM, Jeffrey Ryan wrote:
>
>> Simon,
>>
>> Thanks for the clarifying example. I fear my current set up fails the
>> test for 'no R calls',
>
>Well, but in that case you already have interrupt points so I'm not sure
>what is the problem? I thought the whole point is that you have long
>processing in some 3rd party library where you can't call R API so that's
>why you need the hack in the first place ...
>
>
>> so I think I am stuck on the ugly variant for my
>> current challenge, but I will be able to use this in other places.
>>
>> Thanks again,
>> Jeff
>>
>> On 5/22/12 4:45 PM, "Simon Urbanek" wrote:
>>
>>> Jeff,
>>>
>>> On May 22, 2012, at 4:31 PM, Jeffrey Ryan wrote:
>>>
>>>> I have a continuous loop running in an external library that I am
>>>> calling
>>>> from C (R API). This loop is processing events in real time with the
>>>> possibility of significant lag between events.
>>>>
>>>> When processing an event, I can make use of R_CheckUserInterrupt, but
>>>> while the external library code is waiting on a new event, I don't
>>>>have
>>>> an
>>>> opportunity to call this - my entry points are only on events.
>>>>
>>>
>>> Assuming that while in the library there are no R calls (important!),
>>>you
>>> can use setjmp/longjmp to branch your code depending on whether you
>>>raise
>>> an interrupt or not (see below). This also makes sure that you process
>>> things on the R side properly
>>>
>>> Another alternative is to run your library call on a separate thread
>>>and
>>> have R wait for the result. In that case you don't need to mess with
>>> interrupts since your library code will run separately from R. The
>>> downside is that you need to mess with threads which may or may not be
>>>an
>>> issue depending on the complexity of your code and whether you want it
>>>to
>>> be cross-platform or not.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>> Example code:
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> #include
>>> #include /* only needed if you use
>>> R_interrupts_pending */
>>>
>>> static jmp_buf jenv;
>>>
>>> static void my_int(int sig) {
>>> longjmp(jenv, 1); /* this also restores the interrupt handlers */
>>> }
>>>
>>> SEXP my_R_function(...) {
>>>
>>> if (setjmp(jenv) == 0) { /* enter your protected c
Re: [Rd] Negative years with strptime?
?as.Date
Why would pre years be handled correctly? The help file
explicitly states that they likely will not.
Note:
The default formats follow the rules of the ISO 8601 international
standard which expresses a day as ‘"2001-02-03"’.
If the date string does not specify the date completely, the
returned answer may be system-specific. The most common behaviour
is to assume that a missing year, month or day is the current one.
If it specifies a date incorrectly, reliable implementations will
give an error and the date is reported as ‘NA’. Unfortunately
some common implementations (such as ‘glibc’) are unreliable and
guess at the intended meaning.
Years before 1CE (aka 1AD) will probably not be handled correctly.
On Tue, Jul 10, 2012 at 4:59 PM, Rui Barradas wrote:
> Hello,
>
> Is there a bug with negative dates? Just see:
>
> seq(as.Date("-01-01"), length = 22, by = "-1 year")
> [1] "-01-01" "000/-01-01" "000.-01-01" "000--01-01" "000,-01-01"
> [6] "000+-01-01" "000*-01-01" "000)-01-01" "000(-01-01" "000'-01-01"
> [11] "00/0-01-01" "00//-01-01" "00/.-01-01" "00/--01-01" "00/,-01-01"
> [16] "00/+-01-01" "00/*-01-01" "00/)-01-01" "00/(-01-01" "00/'-01-01"
> [21] "00.0-01-01" "00./-01-01"
>
> See the year number: "after" the zero, i.e., downward from zero, the printed
> character is '/' which happens to be the ascii character before '0', and
> before it's '.', etc. This sequence gives the nine ascii characters before
> zero as last digit of the year, then the 10th is '0' as (now) expected, then
> goes to the second digit, etc.
>
> It seems to stop at the first 9, or else we would have some sort of real
> problem.
>
> Anyway, this doesn't look right.
>
> Rui Barradas
> Em 10-07-2012 22:17, Winston Chang escreveu:
>
>> Is there a way to make as.Date() and strptime() process strings with
>> negative years? It appears that Date objects can contain negative years
>> and
>> you can convert them to strings, but you can't convert them back to Date
>> objects.
>>
>>
>> x <- as.Date(c("0001-01-24", "0500-01-24"))
>> as.character(x)
>> # "0001-01-24" "0500-02-02"
>> as.Date(as.character(x))
>> # "0001-01-24" "0500-01-24"
>>
>> # Minus 391 days gives negative year
>> as.character(x - 391)
>> # "-001-12-30" "0498-12-29"
>>
>> # Can't convert this string back to Date
>> as.Date(as.character(x - 391))
>> # Error during wrapup: character string is not in a standard unambiguous
>> format
>>
>>
>> # as.Date.character uses strptime, so we can try using strptime directly
>> strptime(as.character(x), "%Y-%m-%d")
>> # "0001-01-24" "0500-01-24"
>>
>> strptime(as.character(x - 391), "%Y-%m-%d")
>> # NA "0498-12-29"
>>
>>
>> Thanks,
>> -Winston
>>
>> [[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
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
