Re: [Rd] 'CanMakeUseOf' field
> On 8/29/2006 4:13 PM, Paul Gilbert wrote: >> >> Duncan Murdoch wrote: [...] > > This doesn't address the problem of someone who hasn't got the package > installed yet, though perhaps CRAN could put a version of that man page > (or all of them) online for browsing. Unfortunately this hasn't > happened yet, but maybe we'll get to it before 2.5.0. The help pages are available on CRAN in PDF format, if there are strong preferences to also get the HTML version online that should not be a major problem. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
> Duncan Murdoch <[EMAIL PROTECTED]> writes: >> I think we need an option to R CMD check rather than a new field in the >> DESCRIPTION. Currently a package could be mentioned for any of these >> reasons: >> >> 1. To make functions, examples or vignettes work >> 2. To allow optional functionality in functions, examples or vignettes. >> 3. Because it contains complementary functions. >> >> I don't think we really need to worry about 3: it should be contained >> in 1 or 2, if reasonably complete examples are given. >> >> Case 1 is handled by Depends. > > I think there is an important distinction between a dependency needed > for the package to function and a dependency needed to demonstrate > said functionality via an example or vignette. The former is what > Depends is about, the latter is something else (Suggests). Sorry to join in late, I am at the Compstat conference and have limited email access. What Seth describes in the above paragraph is exactly what I had in mind when splitting the single Depends field we had into Depends and Suggests: Depends are a necessity to run the package, Suggests is nice to have but not necessary. If you know how to use a package you may the decide not to install a package that is only suggested, but * may not be interested to execute the examples, * know that you never need the extra functionality * ... so it should not be auto-installed unless you ask for it (the default could also be the other way round, the point is that it should be possible to have package foo but not the packages it only suggests). On CRAN we check with all suggestions to test all bits and pieces, having an option in R CMD check to test only with suggests may be nice, if there is use for it. Ad the wording in the manual: obviously that is not optimal (otherwise no need for parts of this email thread), perhaps somebody else than the original author (=me) could try to improve it for 2.4 after this clarifications? Otherwise I will give it a shot next week after I return from Rome. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgamma gives zeros. (PR#9184)
I think you fail to understand the floating point arithmetic involved. The smallest floating point number that can be represented to full precision is > .Machine$double.xmin [1] 2.225074e-308 and > pgamma(.Machine$double.xmin, 0.001, rate=0.01) [1] 0.4904533 Your distribution is so extreme that in computer representation it is largely discrete. Now, on your platform there are denormalized doubles, so > table(rgamma(1e6, 0.001, rate=0.01) < .Machine$double.xmin) FALSE TRUE 509073 490927 > table(rgamma(1e6, 0.001, rate=0.01) == 0) FALSE TRUE 525187 474813 > x <- rgamma(1e6, 0.001, rate=0.01) > sort(x[x> 0]) [1:10] [1] 4.940656e-322 4.940656e-322 4.940656e-322 4.940656e-322 4.940656e-322 [6] 4.940656e-322 4.940656e-322 4.940656e-322 4.940656e-322 4.940656e-322 is pretty much what I expected. On Tue, 29 Aug 2006, [EMAIL PROTECTED] wrote: > Full_Name: Peiyi Xi > Version: R 2.2.0 You are specifically asked NOT to report on obselete versions of R. > OS: Windows XP Professional > Submission from: (NULL) (128.2.3.141) > > > When I use rgamma(n, shape, rate ) to generate gamma samples, it > gives zeros when both shape and rate are very small. > > But we know that if x follows a gamma distribution, x should be positive. > > e.g. > > temp=rgamma(10, 0.001, rate=0.01) > > temp > [1] 2.438078e-33 5.101136e-130 1.760830e-54 2.724731e-166 0.00e+00 > [6] 4.461151e-146 1.332914e-55 2.336396e-277 0.00e+00 0.00e+00 > > temp[5] > [1] 0 > > __ > 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] 'CanMakeUseOf' field
> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>> I think we need an option to R CMD check rather than a new field in the
>>> DESCRIPTION. Currently a package could be mentioned for any of these
>>> reasons:
>>>
>>> 1. To make functions, examples or vignettes work
>>> 2. To allow optional functionality in functions, examples or vignettes.
>>> 3. Because it contains complementary functions.
>>>
>>> I don't think we really need to worry about 3: it should be contained
>>> in 1 or 2, if reasonably complete examples are given.
>>>
>>> Case 1 is handled by Depends.
>>
>> I think there is an important distinction between a dependency needed
>> for the package to function and a dependency needed to demonstrate
>> said functionality via an example or vignette. The former is what
>> Depends is about, the latter is something else (Suggests).
FrL> Sorry to join in late, I am at the Compstat conference and have limited
FrL> email access. What Seth describes in the above paragraph is exactly
what I
FrL> had in mind when splitting the single Depends field we had into Depends
FrL> and Suggests: Depends are a necessity to run the package, Suggests is
nice
FrL> to have but not necessary. If you know how to use a package you may the
FrL> decide not to install a package that is only suggested, but
FrL> * may not be interested to execute the examples,
FrL> * know that you never need the extra functionality
FrL> * ...
FrL> so it should not be auto-installed unless you ask for
FrL> it (the default could also be the other way round, the
FrL> point is that it should be possible to have package foo
FrL> but not the packages it only suggests). On CRAN we
FrL> check with all suggestions to test all bits and pieces,
FrL> having an option in R CMD check to test only with
FrL> suggests may be nice, if there is use for it.
Yes.
However, I see two (related) problems with the current 'Suggests'
and that's why I opened this thread proposing to have a
(what I now would want to simply call) 'canUse' :
1) For 'R CMD check' (and hence CRAN checking),
Packages in 'Suggests' must be require()able, and
hence all testing only happens *with* the suggested packages
being there, and not without.
2) "Suggests" suggests to the human reader of DESCRIPTION that
the package authors suggest to also install the packages listed
there.
Now there are cases, I (as package author) want to show some
stuff, or even provide compatibility functionality for some
packages that are related to mine, but which I really do not ``suggest''
to also be installed, e.g., because the other packages do
similar stuff as mine, but I believe my package to be
superior. In such a case, I may, e.g., want to provide
functions for porting the other package classes to my package's.
Duncan Murdoch has proposed to take care of "1)" by
still only use 'Suggests' but adding another option to 'R CMD
check', let's say --no-suggests which would run all the
checks without having the suggested packages available
--- something not quite easy to implement, BTW:
Imagine the typical windows users who (AFAICS) always only use
one library into which they install all packages.
How do you want the
if( require() ) {
...
}
clause *not* to be triggered in such a case ?
I do agree quite a bit that such a '--no-suggests' option would
be very useful for 'R CMD check' -- in addition to my proposal.
Further, I think "2)" above is not taken care of anyway.
After all the interesting statements and alternative proposals,
I'm still proposing to introduce a 'canUse' field for DESCRIPTION
which
a) has a "human-readable intent" of being weaker than 'Suggests'
b) will not require its packages to be available for R CMD check
c) conveys extra information about the package's context, to humans, and
d) will potentially be used in automated or semi-manual
``R package database management''
Martin
FrL> Ad the wording in the manual: obviously that is not
FrL> optimal (otherwise no need for parts of this email
FrL> thread), perhaps somebody else than the original author
FrL> (=me) could try to improve it for 2.4 after this
FrL> clarifications? Otherwise I will give it a shot next
FrL> week after I return from Rome.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
> Duncan Murdoch writes:
> On 8/29/2006 10:12 AM, Martin Maechler wrote:
>>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>>> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
>>
PaulG> Martin Maechler wrote:
>> >> ...
>> >>
>> >> The idea was a field related to but weaker than 'Suggests' :
>> >> Something like
>> >> 'canMakeUseOf: [, , ... ]
>> >> which is *not* used in any QA/QC checking, but is purely
>> >> informative: If is require()able, then some examples may
>> >> look nicer, a function may provide another feature, etc, etc.
>> >> Alternatives to 'canMakeUseOf' would have been
>> >> 'isHappilyCoworkingWith'
>> >>
>> >> What do you (R-devel listeners) think about the idea?
>>
PaulG> I still like this idea. I prefer 'canMakeUseOf' to
PaulG> 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
>>
>> Thanks, Paul.
>> As you may have guessed I should have put a " :-) " beside the
>> 'isHappily...' .
>>
>> Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
>> is rather too long, but before finding the proper term, we should
>> agree on usefulness of such a new field.
>> Apart from the use of package authors {some could note that
>> other packages make use of theirs, without already depending on
>> or suggesting them}, it's one of those fields that should help
>> in the future to explore (e.g. cluster or neighborhood-graph)
>> the growing high-dimensional space of R packages.
> I think we need an option to R CMD check rather than a new field in the
> DESCRIPTION. Currently a package could be mentioned for any of these
> reasons:
> 1. To make functions, examples or vignettes work
> 2. To allow optional functionality in functions, examples or vignettes.
> 3. Because it contains complementary functions.
> I don't think we really need to worry about 3: it should be contained
> in 1 or 2, if reasonably complete examples are given.
> Case 1 is handled by Depends.
> An author should check case 2 both with and without the suggested
> package. A user might be satisfied with a simple check "as things
> currently stand", or might want a stringent check like the author wants.
> The author can't know that, because it will depend on the user.
> So I don't think this is something that should be changed in
> DESCRIPTION. There should be an option to R CMD check to include or
> exclude packages mentioned in the Suggests entry. (I'd suggest a 3
> level option: check as though they are not available, check as
> currently installed, require that they be available.)
An internal environment variable called
_R_CHECK_FORCE_SUGGESTS_
which controls this has been in place for quite some time now. One can
trivially add a Perl R CMD check configure variable for it. I am a bit
hesitant to add a --force-suggests cola to R CMD check, as this
hardwires a legacy dependency model which may not be up to future needs.
As an aside, I have never understood whe developers have need for such
an option (as I would have assumed that they'd typically try to check
all of their code).
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
> Martin Maechler writes: > "FrL" == friedrich leisch <[EMAIL PROTECTED]> > on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes: >>> Duncan Murdoch <[EMAIL PROTECTED]> writes: I think we need an option to R CMD check rather than a new field in the DESCRIPTION. Currently a package could be mentioned for any of these reasons: 1. To make functions, examples or vignettes work 2. To allow optional functionality in functions, examples or vignettes. 3. Because it contains complementary functions. I don't think we really need to worry about 3: it should be contained in 1 or 2, if reasonably complete examples are given. Case 1 is handled by Depends. >>> >>> I think there is an important distinction between a dependency needed >>> for the package to function and a dependency needed to demonstrate >>> said functionality via an example or vignette. The former is what >>> Depends is about, the latter is something else (Suggests). FrL> Sorry to join in late, I am at the Compstat conference and have limited FrL> email access. What Seth describes in the above paragraph is exactly what I FrL> had in mind when splitting the single Depends field we had into Depends FrL> and Suggests: Depends are a necessity to run the package, Suggests is nice FrL> to have but not necessary. If you know how to use a package you may the FrL> decide not to install a package that is only suggested, but FrL> * may not be interested to execute the examples, FrL> * know that you never need the extra functionality FrL> * ... FrL> so it should not be auto-installed unless you ask for FrL> it (the default could also be the other way round, the FrL> point is that it should be possible to have package foo FrL> but not the packages it only suggests). On CRAN we FrL> check with all suggestions to test all bits and pieces, FrL> having an option in R CMD check to test only with FrL> suggests may be nice, if there is use for it. > ... > Further, I think "2)" above is not taken care of anyway. > After all the interesting statements and alternative proposals, > I'm still proposing to introduce a 'canUse' field for DESCRIPTION > which > a) has a "human-readable intent" of being weaker than 'Suggests' > b) will not require its packages to be available for R CMD check > c) conveys extra information about the package's context, to humans, and > d) will potentially be used in automated or semi-manual > ``R package database management'' Martin, I don't think such info should be human-readable. It should be in a standardized format so that we can have tools to compute on such information. E.g., a simple subject-predicate-object model as used in the W3C's semantic web. I am slightly nervous about moving in this direction, though, as I think it implies that repository maintainers deploy processes which validate the semantics of the package metadata. But eventually we will have to do this in any case. -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
Prof Brian Ripley wrote: > No one else seems to have responded to this. > > Please see `Writing R Extensions' for how to time things in R. > > Thank you very much for the pointer to system.time(), although I read most of 'Writing R Extensions', I must have overlooked this (very useful) part. Nevertheless I was aware, that Sys.time() does not measure cpu time (that's why I included the information, that measuring time with Rprof() yields similar results, I had better included the output of Rprof indeed), but I was the only user on both (idle) dual core systems and thus expected a high correlation between the differences of Sys.time() and the cpu time actually used. > For things like this, the fine details of how well the compiler keeps the > pipelines and cache filled are important, as is the cache size and > memory speed. Using > > system.time(for (i in 1:500) ttt <- runif(100)) > > your Linux time looks slow, indeed slower than the only 32-bit Linux box I > have left (a 2GHz 512Kb cache Xeon) and 2.5x slower than a 64-bit R on an > 2.2GHz Opteron (which is doing a lot of other work and so only giving > about 30% of one of its processors to R: the elapsed time was much > longer). > > The binary distribution of R for Windows is compiled with -O3: for some > tasks it makes a lot of difference and this might just be one. > > Thank you very much for this valuable piece of information, it explains a big part of the speed difference: recompiling R on my linux box with -O3 significantly increases speed of runif(), now the linux box needs less than 40% more time than the WinXP system. > However, what can you usefully do in R with 5e8 random uniforms in > anything like a minute, let alone the aggregate time this list will spend > reading your question? The standard method for simulating final, minimal and maximal values of Brownian Motion relies on a (discrete) n-step random walk approximation, where n has to be chosen very large (typically n=100 000) to keep the bias induced by the approximation "small enough" for certain applications. So if you want to do MC option pricing of e.g. double barrier options, 5e8 random uniforms are needed for 5 000 draws of final, minimal and maximal value, which is still a quite small number of draws in MC applications. I am working on a faster simulation method and of course I want to compare the speed of the new and (old) standard method, that's why I needed large numbers of random uniforms. I thought that the particular application is not of interest for this list, so I left it out in my initial submission. I apologise, if my submission was off-topic in this mailing list. > If it matters to you, investigate the code your > compiler creates. (The ATLAS developers report very poor performance on > certain Pentiums for certain versions of gcc4.) > > Thank you again for the useful hints! Regards, Martin Becker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
On Wed, 30 Aug 2006, Martin Becker wrote: > Prof Brian Ripley wrote: > > No one else seems to have responded to this. > > > > Please see `Writing R Extensions' for how to time things in R. > > > Thank you very much for the pointer to system.time(), although I read most of > 'Writing R Extensions', I must have overlooked this (very useful) part. > Nevertheless I was aware, that Sys.time() does not measure cpu time (that's > why I included the information, that measuring time with Rprof() yields > similar results, I had better included the output of Rprof indeed), but I was > the only user on both (idle) dual core systems and thus expected a high > correlation between the differences of Sys.time() and the cpu time actually > used. Actually, Rprof does time elapsed time on Windows. Calling gc() first is important, and part of what system.time() does. > > For things like this, the fine details of how well the compiler keeps the > > pipelines and cache filled are important, as is the cache size and memory > > speed. Using > > > > system.time(for (i in 1:500) ttt <- runif(100)) > > > > your Linux time looks slow, indeed slower than the only 32-bit Linux box I > > have left (a 2GHz 512Kb cache Xeon) and 2.5x slower than a 64-bit R on an > > 2.2GHz Opteron (which is doing a lot of other work and so only giving about > > 30% of one of its processors to R: the elapsed time was much longer). > > > > The binary distribution of R for Windows is compiled with -O3: for some > > tasks it makes a lot of difference and this might just be one. > > > Thank you very much for this valuable piece of information, it explains a big > part of the speed difference: recompiling R on my linux box with -O3 > significantly increases speed of runif(), now the linux box needs less than > 40% more time than the WinXP system. > > However, what can you usefully do in R with 5e8 random uniforms in anything > > like a minute, let alone the aggregate time this list will spend reading > > your question? > The standard method for simulating final, minimal and maximal values of > Brownian Motion relies on a (discrete) n-step random walk approximation, where > n has to be chosen very large (typically n=100 000) to keep the bias induced > by the approximation "small enough" for certain applications. So if you want > to do MC option pricing of e.g. double barrier options, 5e8 random uniforms > are needed for 5 000 draws of final, minimal and maximal value, which is still > a quite small number of draws in MC applications. I am working on a faster > simulation method and of course I want to compare the speed of the new and > (old) standard method, that's why I needed large numbers of random uniforms. I > thought that the particular application is not of interest for this list, so I > left it out in my initial submission. I apologise, if my submission was > off-topic in this mailing list. Isn't that usually done by adding rnorm()s and not runif()s? There are much better algorithms for simulating Brownian motion barrier-crossing statistics to high accuracy. It's not my field, but one idea is to use scaled Brownian bridge to infill time when the process is near a boundary. Sometimes the R helpers spend a long time answering the wrong question, which is why it always helps to give the real one. > > If it matters to you, investigate the code your compiler creates. (The > > ATLAS developers report very poor performance on certain Pentiums for > > certain versions of gcc4.) > > > > > Thank you again for the useful hints! > > Regards, > > Martin Becker > > -- 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] 'CanMakeUseOf' field
On 8/30/2006 3:21 AM, [EMAIL PROTECTED] wrote: >> On 8/29/2006 4:13 PM, Paul Gilbert wrote: >>> Duncan Murdoch wrote: > > [...] > >> This doesn't address the problem of someone who hasn't got the package >> installed yet, though perhaps CRAN could put a version of that man page >> (or all of them) online for browsing. Unfortunately this hasn't >> happened yet, but maybe we'll get to it before 2.5.0. > > The help pages are available on CRAN in PDF format, if there are strong > preferences to also get the HTML version online that should not be a major > problem. Just to clarify: "this hasn't happened yet" was meant to apply to the earlier part of my message, the changes necessary to make the package man page easier to maintain. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
On 8/30/2006 6:33 AM, Prof Brian Ripley wrote: > On Wed, 30 Aug 2006, Martin Becker wrote: > >> Prof Brian Ripley wrote: >>> No one else seems to have responded to this. >>> >>> Please see `Writing R Extensions' for how to time things in R. >>> >> Thank you very much for the pointer to system.time(), although I read most of >> 'Writing R Extensions', I must have overlooked this (very useful) part. >> Nevertheless I was aware, that Sys.time() does not measure cpu time (that's >> why I included the information, that measuring time with Rprof() yields >> similar results, I had better included the output of Rprof indeed), but I was >> the only user on both (idle) dual core systems and thus expected a high >> correlation between the differences of Sys.time() and the cpu time actually >> used. > > Actually, Rprof does time elapsed time on Windows. Calling gc() first is > important, and part of what system.time() does. > >>> For things like this, the fine details of how well the compiler keeps the >>> pipelines and cache filled are important, as is the cache size and memory >>> speed. Using >>> >>> system.time(for (i in 1:500) ttt <- runif(100)) >>> >>> your Linux time looks slow, indeed slower than the only 32-bit Linux box I >>> have left (a 2GHz 512Kb cache Xeon) and 2.5x slower than a 64-bit R on an >>> 2.2GHz Opteron (which is doing a lot of other work and so only giving about >>> 30% of one of its processors to R: the elapsed time was much longer). >>> >>> The binary distribution of R for Windows is compiled with -O3: for some >>> tasks it makes a lot of difference and this might just be one. >>> >> Thank you very much for this valuable piece of information, it explains a big >> part of the speed difference: recompiling R on my linux box with -O3 >> significantly increases speed of runif(), now the linux box needs less than >> 40% more time than the WinXP system. >>> However, what can you usefully do in R with 5e8 random uniforms in anything >>> like a minute, let alone the aggregate time this list will spend reading >>> your question? >> The standard method for simulating final, minimal and maximal values of >> Brownian Motion relies on a (discrete) n-step random walk approximation, >> where >> n has to be chosen very large (typically n=100 000) to keep the bias induced >> by the approximation "small enough" for certain applications. So if you want >> to do MC option pricing of e.g. double barrier options, 5e8 random uniforms >> are needed for 5 000 draws of final, minimal and maximal value, which is >> still >> a quite small number of draws in MC applications. I am working on a faster >> simulation method and of course I want to compare the speed of the new and >> (old) standard method, that's why I needed large numbers of random uniforms. >> I >> thought that the particular application is not of interest for this list, so >> I >> left it out in my initial submission. I apologise, if my submission was >> off-topic in this mailing list. > > Isn't that usually done by adding rnorm()s and not runif()s? > > There are much better algorithms for simulating Brownian motion > barrier-crossing statistics to high accuracy. It's not my field, but one > idea is to use scaled Brownian bridge to infill time when the process is > near a boundary. McLeish published algorithms to simulate these directly in a recent issue of CJS. I don't have the reference handy, but I think it's 2004 or 2005. Duncan Murdoch > > Sometimes the R helpers spend a long time answering the wrong question, > which is why it always helps to give the real one. > >>> If it matters to you, investigate the code your compiler creates. (The >>> ATLAS developers report very poor performance on certain Pentiums for >>> certain versions of gcc4.) >>> >>> >> Thank you again for the useful hints! >> >> Regards, >> >> Martin Becker >> >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inaccuracy in seq() (PR#9189)
Full_Name: Mark James Kelly Version: 2.3.1 OS: Windows Submission from: (NULL) (193.63.127.224) Sequence produces slightly inaccurate results. #This (supposedely) creates a sequence 0.060,0.065,0.070.0.30 thingnor=(seq(0.06,0.30,by=0.005)) #This does the same but rounds to three decimals thingrou=round(seq(0.06,0.30,by=0.005),3) #This is another vector, the same length as the two above, with 24 zeroes, then 0.070, then 24 zeroes otherthing=c(rep(0,24),0.070,rep(0,24)) #This fails to select the entries equal to 0.070 otherthing[otherthing==thingnor[3]] #This gives the correct answer otherthing[otherthing==thingrou[3]] #This compares the two sequences (which should be identical) (thingnor-thingrou) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
Prof Brian Ripley schrieb: >> The standard method for simulating final, minimal and maximal values of >> Brownian Motion relies on a (discrete) n-step random walk approximation, >> where >> n has to be chosen very large (typically n=100 000) to keep the bias induced >> by the approximation "small enough" for certain applications. So if you want >> to do MC option pricing of e.g. double barrier options, 5e8 random uniforms >> are needed for 5 000 draws of final, minimal and maximal value, which is >> still >> a quite small number of draws in MC applications. I am working on a faster >> simulation method and of course I want to compare the speed of the new and >> (old) standard method, that's why I needed large numbers of random uniforms. >> I >> thought that the particular application is not of interest for this list, so >> I >> left it out in my initial submission. I apologise, if my submission was >> off-topic in this mailing list. >> > > Isn't that usually done by adding rnorm()s and not runif()s? > > There are much better algorithms for simulating Brownian motion > barrier-crossing statistics to high accuracy. It's not my field, but one > idea is to use scaled Brownian bridge to infill time when the process is > near a boundary. > > Sometimes the R helpers spend a long time answering the wrong question, > which is why it always helps to give the real one. > As I wrote, I am working on (an implementation of) a faster method, which indeed uses Brownian bridge and related concepts, and I generated the huge number of random uniforms (random normals are better but still slower) just for speed comparison. So for me, the real question was about the speed difference of runif(). Thanks again, regards, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
Duncan Murdoch schrieb: > > McLeish published algorithms to simulate these directly in a recent > issue of CJS. I don't have the reference handy, but I think it's 2004 > or 2005. > > Duncan Murdoch Thank you for this reference, I think it is the 2002 article "*Highs and lows: Some properties of the extremes of a diffusion and applications in finance"*. This article perfectly covers simulation of final and minimal or final and maximal value and gives some proposals for the simulation of the third component (max resp. min). In principle my implementation of the simulation of the first two components coincides with the algorithm given in this paper. Thanks again, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccuracy in seq() (PR#9189)
On Wed, 30 Aug 2006 [EMAIL PROTECTED] wrote: > Full_Name: Mark James Kelly > Version: 2.3.1 > OS: Windows > Submission from: (NULL) (193.63.127.224) > > > Sequence produces slightly inaccurate results. Not a bug, but a FAQ (7.31): http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f Try: otherthing[25]==thingnor[3] identical(otherthing[25], thingnor[3]) all.equal(otherthing[25], thingnor[3]) ?all.equal > > #This (supposedely) creates a sequence 0.060,0.065,0.070.0.30 > thingnor=(seq(0.06,0.30,by=0.005)) > > #This does the same but rounds to three decimals > thingrou=round(seq(0.06,0.30,by=0.005),3) > > #This is another vector, the same length as the two above, with 24 zeroes, > then > 0.070, then 24 zeroes > otherthing=c(rep(0,24),0.070,rep(0,24)) > > > #This fails to select the entries equal to 0.070 > otherthing[otherthing==thingnor[3]] > > #This gives the correct answer > otherthing[otherthing==thingrou[3]] > > > #This compares the two sequences (which should be identical) > (thingnor-thingrou) > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccuracy in seq() (PR#9189)
See the FAQ Q7.31: 0.07 is not exactly representable on your computer.
0.060 + 2*0.005 != 0.070 in computer arithmetic:
> options(digits=18)
> 0.060
[1] 0.06
> 0.070
[1] 0.070007
> 0.060+2*0.005
[1] 0.06999
> 0.06+2*0.005 -0.07
[1] -1.3877787807814457e-17
> .Machine$double.eps * 0.07
[1] 1.5543122344752193e-17
On Wed, 30 Aug 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Mark James Kelly
> Version: 2.3.1
> OS: Windows
> Submission from: (NULL) (193.63.127.224)
>
>
> Sequence produces slightly inaccurate results.
sequence() is a different function in R.
> #This (supposedely) creates a sequence 0.060,0.065,0.070.0.30
> thingnor=(seq(0.06,0.30,by=0.005))
>
> #This does the same but rounds to three decimals
> thingrou=round(seq(0.06,0.30,by=0.005),3)
>
> #This is another vector, the same length as the two above, with 24 zeroes,
> then
> 0.070, then 24 zeroes
> otherthing=c(rep(0,24),0.070,rep(0,24))
>
>
> #This fails to select the entries equal to 0.070
> otherthing[otherthing==thingnor[3]]
>
> #This gives the correct answer
> otherthing[otherthing==thingrou[3]]
>
>
> #This compares the two sequences (which should be identical)
> (thingnor-thingrou)
Not according to FAQ Q7.31 and help("==").
--
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] 'CanMakeUseOf' field
> On 8/30/2006 3:21 AM, [EMAIL PROTECTED] wrote: >>> On 8/29/2006 4:13 PM, Paul Gilbert wrote: Duncan Murdoch wrote: >> >> [...] >> >>> This doesn't address the problem of someone who hasn't got the package >>> installed yet, though perhaps CRAN could put a version of that man page >>> (or all of them) online for browsing. Unfortunately this hasn't >>> happened yet, but maybe we'll get to it before 2.5.0. >> >> The help pages are available on CRAN in PDF format, if there are strong >> preferences to also get the HTML version online that should not be a >> major >> problem. > > Just to clarify: "this hasn't happened yet" was meant to apply to the > earlier part of my message, the changes necessary to make the package > man page easier to maintain. Sure, that is how I read it (sorry for not deleting your last sentence in my reply). The question remains wether we should put HTML pages of all package help pages on CRAN? Kurt builds them anyway when checking the packages, so it is mostly a matter of copying them into the HTTP tree and some linking. Why we did not do it so far is that it really increases the size of mirrors a lot, as those files would not be compressed (nd there are heaps of them). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
On 8/30/2006 7:44 AM, Martin Becker wrote: > Duncan Murdoch schrieb: >> >> McLeish published algorithms to simulate these directly in a recent >> issue of CJS. I don't have the reference handy, but I think it's 2004 >> or 2005. >> >> Duncan Murdoch > Thank you for this reference, I think it is the 2002 article "*Highs and > lows: Some properties of the extremes of a diffusion and applications in > finance"*. Yes, that's it. Duncan Murdoch > This article perfectly covers simulation of final and minimal or final > and maximal value and gives some proposals for the simulation of the > third component (max resp. min). In principle my implementation of the > simulation of the first two components coincides with the algorithm > given in this paper. > > Thanks again, > > Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
>> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
>> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>
> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
> >>> I think we need an option to R CMD check rather than a new field
> in the
> >>> DESCRIPTION. Currently a package could be mentioned for any of
> these
> >>> reasons:
> >>>
> >>> 1. To make functions, examples or vignettes work
> >>> 2. To allow optional functionality in functions, examples or
> vignettes.
> >>> 3. Because it contains complementary functions.
> >>>
> >>> I don't think we really need to worry about 3: it should be
> contained
> >>> in 1 or 2, if reasonably complete examples are given.
> >>>
> >>> Case 1 is handled by Depends.
> >>
> >> I think there is an important distinction between a dependency
> needed
> >> for the package to function and a dependency needed to demonstrate
> >> said functionality via an example or vignette. The former is what
> >> Depends is about, the latter is something else (Suggests).
>
> FrL> Sorry to join in late, I am at the Compstat conference and have
> limited
> FrL> email access. What Seth describes in the above paragraph is
> exactly what I
> FrL> had in mind when splitting the single Depends field we had into
> Depends
> FrL> and Suggests: Depends are a necessity to run the package,
> Suggests is nice
> FrL> to have but not necessary. If you know how to use a package you
> may the
> FrL> decide not to install a package that is only suggested, but
>
> FrL> * may not be interested to execute the examples,
> FrL> * know that you never need the extra functionality
> FrL> * ...
>
> FrL> so it should not be auto-installed unless you ask for
> FrL> it (the default could also be the other way round, the
> FrL> point is that it should be possible to have package foo
> FrL> but not the packages it only suggests). On CRAN we
> FrL> check with all suggestions to test all bits and pieces,
> FrL> having an option in R CMD check to test only with
> FrL> suggests may be nice, if there is use for it.
>
> Yes.
> However, I see two (related) problems with the current 'Suggests'
> and that's why I opened this thread proposing to have a
> (what I now would want to simply call) 'canUse' :
>
> 1) For 'R CMD check' (and hence CRAN checking),
>Packages in 'Suggests' must be require()able, and
>hence all testing only happens *with* the suggested packages
>being there, and not without.
>
> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>the package authors suggest to also install the packages listed
>there.
>Now there are cases, I (as package author) want to show some
>stuff, or even provide compatibility functionality for some
>packages that are related to mine, but which I really do not
> ``suggest''
>to also be installed, e.g., because the other packages do
>similar stuff as mine, but I believe my package to be
>superior. In such a case, I may, e.g., want to provide
>functions for porting the other package classes to my package's.
>
> Duncan Murdoch has proposed to take care of "1)" by
> still only use 'Suggests' but adding another option to 'R CMD
> check', let's say --no-suggests which would run all the
> checks without having the suggested packages available
> --- something not quite easy to implement, BTW:
> Imagine the typical windows users who (AFAICS) always only use
> one library into which they install all packages.
> How do you want the
> if( require() ) {
>...
> }
> clause *not* to be triggered in such a case ?
> I do agree quite a bit that such a '--no-suggests' option would
> be very useful for 'R CMD check' -- in addition to my proposal.
>
> Further, I think "2)" above is not taken care of anyway.
> After all the interesting statements and alternative proposals,
> I'm still proposing to introduce a 'canUse' field for DESCRIPTION
> which
> a) has a "human-readable intent" of being weaker than 'Suggests'
> b) will not require its packages to be available for R CMD check
> c) conveys extra information about the package's context, to humans, and
> d) will potentially be used in automated or semi-manual
> ``R package database management''
>
Sorry, I did not want to give the impression of ignoring your proposal,
but wanted to clarify the ratio behid what we currently have first and
then ran out of time. I agree that a new field like you describe above can
be very usefull, the only thing I worry about is if it makes life really
easier or if it confuses users and developers even more.
Debian has Depends/Recommends/Suggests and after 10 years of using Debian
I would still have to got to the Debian guidelines to learn what the exact
difference between the latter two is. There certainly is a distinction,
and I knew it at some point in time, but when I read a package descr
[Rd] "Enhances" (Was: 'CanMakeUseOf' field)
On 30 August 2006 at 14:04, [EMAIL PROTECTED] wrote: | Debian has Depends/Recommends/Suggests and after 10 years of using Debian | I would still have to got to the Debian guidelines to learn what the exact | difference between the latter two is. There certainly is a distinction, It's all defined somewhere, but I by and large second the sentiment. Now, while we're at it, Debian also has a field called "Enhances:" and IIRC it provides a means to communicate a relationship 'the other way'. Ie a package foo, rather than being 'pulled in' by a package bar via a Depends, makes itself available to bar. That is useful as you can enhance the 'graph' structure without a change in the other package. Maybe that would be of use for R too? Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 Methods dispatch
A revision of r-devel 2.4.0 is being committed today with changes to method and class management. The changes are internal but extensive. All packages that use S4 methods and classes need to be reinstalled from source to use the new version. The main effects are to speed up method caching and dispatch, and to fix some problems with selecting inherited methods. The new design is also cleaner, so we can experiment more easily in the future with changes for efficiency or semantics. The change will mostly be noticeable in attaching packages with many methods. The CPU time for attaching package Matrix, for example, goes down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5. The other major change is that now _all_ inherited methods are examined and one of the closest matches is chosen. The old selection took the first candidate found, so the current version is better defined, and will also let us experiment with various tuning & strategies. There is a draft paper describing method selection at http://developer.r-project.org/howMethodsWork.pdf (It's a document in progress, so go back in a few days for a revised version.) If a package uses inheritance for method selection with multiple arguments, there may well be changes in behavior. We found examples in both methods itself and in Matrix that needed attention. John __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Kurt Hornik <[EMAIL PROTECTED]> writes: > An internal environment variable called > > _R_CHECK_FORCE_SUGGESTS_ > > which controls this has been in place for quite some time now. One can > trivially add a Perl R CMD check configure variable for it. I am a bit > hesitant to add a --force-suggests cola to R CMD check, as this > hardwires a legacy dependency model which may not be up to future needs. > > As an aside, I have never understood whe developers have need for such > an option (as I would have assumed that they'd typically try to check > all of their code). This is not an aside, but the heart of the issue IMHO :-) One case in which checking Suggests does not make sense is when a package provides optional functionality that is platform specific. A given Suggests entry may only be available on platform A, but it still is desirable to check the package on platform B. Similar issues can arise during development when a given Suggests entry stops working with R-devel. Further, if an item in Suggests means it is optional, then one _should_ test that by testing the package without the optional packge being available. There are a few ways for a true dependency to sneak into the code. So I agree that typically developers want to test all of their code, but that implies being able to check a package without its Suggests being available (I realize this may be hard to implement, but easily having R CMD check ignore Suggests is a good start). And lastly, Suggests is currently used to list packages used for extended examples in package vignettes and being able to easily perform all other checks makes sense to me. Bw, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/30/2006 4:44 AM, Martin Maechler wrote:
>> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
>> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>
> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
> >>> I think we need an option to R CMD check rather than a new field in
> the
> >>> DESCRIPTION. Currently a package could be mentioned for any of these
> >>> reasons:
> >>>
> >>> 1. To make functions, examples or vignettes work
> >>> 2. To allow optional functionality in functions, examples or
> vignettes.
> >>> 3. Because it contains complementary functions.
> >>>
> >>> I don't think we really need to worry about 3: it should be contained
> >>> in 1 or 2, if reasonably complete examples are given.
> >>>
> >>> Case 1 is handled by Depends.
> >>
> >> I think there is an important distinction between a dependency needed
> >> for the package to function and a dependency needed to demonstrate
> >> said functionality via an example or vignette. The former is what
> >> Depends is about, the latter is something else (Suggests).
>
> FrL> Sorry to join in late, I am at the Compstat conference and have
> limited
> FrL> email access. What Seth describes in the above paragraph is exactly
> what I
> FrL> had in mind when splitting the single Depends field we had into
> Depends
> FrL> and Suggests: Depends are a necessity to run the package, Suggests
> is nice
> FrL> to have but not necessary. If you know how to use a package you may
> the
> FrL> decide not to install a package that is only suggested, but
>
> FrL> * may not be interested to execute the examples,
> FrL> * know that you never need the extra functionality
> FrL> * ...
>
> FrL> so it should not be auto-installed unless you ask for
> FrL> it (the default could also be the other way round, the
> FrL> point is that it should be possible to have package foo
> FrL> but not the packages it only suggests). On CRAN we
> FrL> check with all suggestions to test all bits and pieces,
> FrL> having an option in R CMD check to test only with
> FrL> suggests may be nice, if there is use for it.
>
> Yes.
> However, I see two (related) problems with the current 'Suggests'
> and that's why I opened this thread proposing to have a
> (what I now would want to simply call) 'canUse' :
>
> 1) For 'R CMD check' (and hence CRAN checking),
>Packages in 'Suggests' must be require()able, and
>hence all testing only happens *with* the suggested packages
>being there, and not without.
>
> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>the package authors suggest to also install the packages listed
>there.
>Now there are cases, I (as package author) want to show some
>stuff, or even provide compatibility functionality for some
>packages that are related to mine, but which I really do not ``suggest''
>to also be installed, e.g., because the other packages do
>similar stuff as mine, but I believe my package to be
>superior. In such a case, I may, e.g., want to provide
>functions for porting the other package classes to my package's.
>
> Duncan Murdoch has proposed to take care of "1)" by
> still only use 'Suggests' but adding another option to 'R CMD
> check', let's say --no-suggests which would run all the
> checks without having the suggested packages available
> --- something not quite easy to implement, BTW:
> Imagine the typical windows users who (AFAICS) always only use
> one library into which they install all packages.
> How do you want the
> if( require() ) {
>...
> }
> clause *not* to be triggered in such a case ?
I would expect require to return FALSE. This could be done by check
installing a new version of require() (as it installs new T and F), or
by the standard require() being modified to check a stop list before
acting (I'd prefer this, because it would make it easier for developers
to experiment with functions in different environments), or by playing
around with the names of things in the library (probably not workable on
Windows), etc.
I think the default check behaviour on CRAN should be my middle case:
test based on what is currently installed, don't require packages listed
in Suggests to be installed. I'm not sure if that should be the default
behaviour for R CMD check at the command line: as Kurt said, usually a
developer wants to check all of the code.
> I do agree quite a bit that such a '--no-suggests' option would
> be very useful for 'R CMD check' -- in addition to my proposal.
I think the other extreme (which I think is there now as
_R_CHECK_FORCE_SUGGESTS_) is also important.
>
> Further, I think "2)" above is not taken care of anyway.
> After all the interesting statements and alternative proposals,
> I'm still proposing to introduce a 'canUse' field for DESCRIPTION
> which
> a)
[Rd] setMethod() and log()
Hi
I am having difficulty with setMethod(). I have a "brob" class of
objects whose
representation has two slots: "x" and "positive". Slot "x" (double)
holds the log
of a number and slot "positive" (logical) its sign. The idea is
that large numbers
can be handled.
I'm trying to implement a log() method using an analogue of the
setMethod() example
for polynomials on page 117 of V&R. abs() works [I think], but log()
doesn't:
[transcript follows, source for the classes below]
> a <- as.brob((-4:4 )+0.4)
> a
An object of class "brob"
Slot "x":
[1] 1.2809338 0.9555114 0.4700036 -0.5108256 -0.9162907
0.3364722 0.8754687
[8] 1.2237754 1.4816045
Slot "positive":
[1] FALSE FALSE FALSE FALSE TRUE TRUE TRUE TRUE TRUE
> abs(a)
An object of class "brob"
Slot "x":
[1] 1.2809338 0.9555114 0.4700036 -0.5108256 -0.9162907
0.3364722 0.8754687
[8] 1.2237754 1.4816045
Slot "positive":
[1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
# This works: each element is now positive.
> log(a)
Error in log(x) : Non-numeric argument to mathematical function
>
What's wrong with my setMethod() call below?
setClass("brob",
representation = representation
(x="numeric",positive="logical"),
prototype = list(x=numeric(),positive=logical())
)
setAs("brob", "numeric", function(from){
out <- exp([EMAIL PROTECTED])
[EMAIL PROTECTED] <- [EMAIL PROTECTED]
return(out)
}
)
setMethod("as.numeric",signature(x="brob"),function(x){as(x,"numeric")})
is.brob <- function(x){is(x,"brob")}
"brob" <- function(x,positive){
if(missing(positive)){
positive <- rep(TRUE,length(x))
}
if(length(positive)==1){
positive <- rep(positive,length(x))
}
new("brob",x=x,positive=positive)
}
as.brob <- function(x){
brob(log(abs(x)),x>0)
}
setMethod("Math", "brob",
function(x){
switch(.Generic,
abs= brob([EMAIL PROTECTED]),
log= { out <- [EMAIL PROTECTED]
[EMAIL PROTECTED] <- NaN
out
},
acos =,
acosh =,
asin =,
asinh =,
atan =,
atanh =,
ceiling=,
cos=,
cosh =,
cumsum =,
exp=,
floor =,
gamma =,
lgamma =,
sin=,
sinh =,
tan=,
tanh =,
trunc = as.brob(callGeneric(as.numeric(x))),
stop(paste(.Generic, "not allowed on
Brobdingnagian numbers"))
)
}
)
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Enhances"
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Now, while we're at it, Debian also has a field called "Enhances:" and IIRC > it provides a means to communicate a relationship 'the other way'. Ie a > package foo, rather than being 'pulled in' by a package bar via a Depends, > makes itself available to bar. That is useful as you can enhance the > 'graph' structure without a change in the other package. Maybe that would be > of use for R too? Such a field DependsOnMe might be useful in some cases, but one can compute that using the dependency graph. One just needs a bit of code... [shameless plug] I have an almost complete package 'pkgDepTools' that provides tools for computing and analyzing dependency relationships among R packages. It provides tools for building a graph-based representation of the dependencies among all packages in a list of CRAN-style package repositories. There are also utilities for computing installation order of a given package. If the RCurl package is available, an estimate of the download size required to install a given package and its dependencies can be obtained. It should be available in Bioconductor in the next couple of weeks. Bw, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installation error (PR#9190)
Full_Name: Patrick Lenon Version: 2.3.1 OS: Solaris 10 Submission from: (NULL) (144.92.92.204) During ./configure of R 2.3.1 (R-home directory of `/u/home/lenon/R/ru231/') I got this feedback shown below. configure: WARNING: floatingpoint.h: present but cannot be compiled configure: WARNING: floatingpoint.h: check for missing prerequisite headers? configure: WARNING: floatingpoint.h: see the Autoconf documentation configure: WARNING: floatingpoint.h: section "Present But Cannot Be Compiled" configure: WARNING: floatingpoint.h: proceeding with the preprocessor's result configure: WARNING: floatingpoint.h: in the future, the compiler will take precedence configure: WARNING: ## --- ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## --- ## Subsequently the "make" failed with this error: /usr/local/include/stdio.h:186: error: conflicting types for `FILE' /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.1/include/floatingpoint.h:52: error: previous declaration of `FILE' make[3]: *** [bakslv.o] Error 1 make[3]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src/appl' make[2]: *** [R] Error 2 make[2]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src/appl' make[1]: *** [R] Error 1 make[1]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src' make: *** [R] Error 1 I did a search for 'floatingpoint.h' in the R bug archive and got no results. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Duplicated definition of helper in available.packages
Hi,
The .checkRversion helper function is defined twice in
available.packages. I'm pretty sure one definition will suffice.
Untested patch below.
+ seth
diff --git a/src/library/utils/R/packages.R b/src/library/utils/R/packages.R
index 0b84f02..5184992 100644
--- a/src/library/utils/R/packages.R
+++ b/src/library/utils/R/packages.R
@@ -86,13 +86,6 @@ available.packages <-
}
## ignore packages which don't fit our version of R
if(length(res)) {
-.checkRversion <- function(x) {
-if(is.na(xx <- x["Depends"])) return(TRUE)
-xx <- tools:::.split_dependencies(xx)
-if(length(z <- xx[["R"]]) > 1)
-eval(parse(text=paste("currentR", z$op, "z$version")))
-else TRUE
-}
currentR <- getRversion()
res <- res[apply(res, 1, .checkRversion), , drop=FALSE]
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setMethod() and log()
Hi Robin,
from reading ?Math:
Note: currently those members which are not primitive functions
must have been converted to S4 generic functions (preferably
_before_ setting an S4 group generic method) as it only sets
methods for known S4 generics. This can be done by a call to
'setGeneric', for example 'setGeneric("round", group="Math2")'.
so
setGeneric("log", group="Math")
before setMethod("Math", ...) seems to do the trick (perhaps at the
expense of adding explicit S4 method dispatch to log). The difference
between abs and log is apparent from looking at their definitions
> abs
.Primitive("abs")
> log
function (x, base = exp(1))
if (missing(base)) .Internal(log(x)) else .Internal(log(x, base))
Hope that removes some uncertainty.
Martin
--
Bioconductor
Robin Hankin <[EMAIL PROTECTED]> writes:
> Hi
>
> I am having difficulty with setMethod(). I have a "brob" class of
> objects whose
> representation has two slots: "x" and "positive". Slot "x" (double)
> holds the log
> of a number and slot "positive" (logical) its sign. The idea is
> that large numbers
> can be handled.
>
> I'm trying to implement a log() method using an analogue of the
> setMethod() example
> for polynomials on page 117 of V&R. abs() works [I think], but log()
> doesn't:
>
> [transcript follows, source for the classes below]
>
>
>
> > a <- as.brob((-4:4 )+0.4)
> > a
> An object of class "brob"
> Slot "x":
> [1] 1.2809338 0.9555114 0.4700036 -0.5108256 -0.9162907
> 0.3364722 0.8754687
> [8] 1.2237754 1.4816045
>
> Slot "positive":
> [1] FALSE FALSE FALSE FALSE TRUE TRUE TRUE TRUE TRUE
>
> > abs(a)
> An object of class "brob"
> Slot "x":
> [1] 1.2809338 0.9555114 0.4700036 -0.5108256 -0.9162907
> 0.3364722 0.8754687
> [8] 1.2237754 1.4816045
>
> Slot "positive":
> [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
>
> # This works: each element is now positive.
>
> > log(a)
> Error in log(x) : Non-numeric argument to mathematical function
> >
>
>
>
> What's wrong with my setMethod() call below?
>
>
>
>
>
> setClass("brob",
> representation = representation
> (x="numeric",positive="logical"),
> prototype = list(x=numeric(),positive=logical())
> )
>
> setAs("brob", "numeric", function(from){
>out <- exp([EMAIL PROTECTED])
>[EMAIL PROTECTED] <- [EMAIL PROTECTED]
>return(out)
> }
>)
>
> setMethod("as.numeric",signature(x="brob"),function(x){as(x,"numeric")})
>
> is.brob <- function(x){is(x,"brob")}
>
> "brob" <- function(x,positive){
>if(missing(positive)){
> positive <- rep(TRUE,length(x))
>}
>if(length(positive)==1){
> positive <- rep(positive,length(x))
>}
>new("brob",x=x,positive=positive)
> }
>
> as.brob <- function(x){
>brob(log(abs(x)),x>0)
> }
>
> setMethod("Math", "brob",
>function(x){
> switch(.Generic,
> abs= brob([EMAIL PROTECTED]),
> log= { out <- [EMAIL PROTECTED]
>[EMAIL PROTECTED] <- NaN
>out
> },
> acos =,
> acosh =,
> asin =,
> asinh =,
> atan =,
> atanh =,
> ceiling=,
> cos=,
> cosh =,
> cumsum =,
> exp=,
> floor =,
> gamma =,
> lgamma =,
> sin=,
> sinh =,
> tan=,
> tanh =,
> trunc = as.brob(callGeneric(as.numeric(x))),
> stop(paste(.Generic, "not allowed on
> Brobdingnagian numbers"))
> )
>}
>)
>
>
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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] Installation error (PR#9190)
This is a bug in your compiler installation, not one in R.
I notice you have a very old version of gcc, and that you have a system
header (stdio.h) in /usr/local/include.
It seems likely that you have a version of the mismatch problem discussed
in the R-admin manual:
@command{gcc} makes modified versions of some header files, and
so (for example) @command{gcc} compiled under Solaris 2.6 will not
compile @R{} under Solaris 2.7.
On Wed, 30 Aug 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Patrick Lenon
> Version: 2.3.1
> OS: Solaris 10
> Submission from: (NULL) (144.92.92.204)
>
>
> During ./configure of R 2.3.1 (R-home directory of `/u/home/lenon/R/ru231/') I
> got this feedback shown below.
>
> configure: WARNING: floatingpoint.h: present but cannot be compiled
> configure: WARNING: floatingpoint.h: check for missing prerequisite
> headers?
> configure: WARNING: floatingpoint.h: see the Autoconf documentation
> configure: WARNING: floatingpoint.h: section "Present But Cannot Be
> Compiled"
> configure: WARNING: floatingpoint.h: proceeding with the preprocessor's result
> configure: WARNING: floatingpoint.h: in the future, the compiler will take
> precedence
> configure: WARNING: ## --- ##
> configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
> configure: WARNING: ## --- ##
>
> Subsequently the "make" failed with this error:
>
> /usr/local/include/stdio.h:186: error: conflicting types for `FILE'
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.1/include/floatingpoint.h:52:
> error: previous declaration of `FILE'
> make[3]: *** [bakslv.o] Error 1
> make[3]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src/appl'
> make[2]: *** [R] Error 2
> make[2]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src/appl'
> make[1]: *** [R] Error 1
> make[1]: Leaving directory `/u/home/lenon/R/ru231/R-2.3.1/src'
> make: *** [R] Error 1
>
> I did a search for 'floatingpoint.h' in the R bug archive and got no results.
>
> __
> 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] 'CanMakeUseOf' field
Duncan Murdoch wrote:
> On 8/30/2006 4:44 AM, Martin Maechler wrote:
>>> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
>>> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>> >>> I think we need an option to R CMD check rather than a new field in
>> the
>> >>> DESCRIPTION. Currently a package could be mentioned for any of these
>> >>> reasons:
>> >>>
>> >>> 1. To make functions, examples or vignettes work
>> >>> 2. To allow optional functionality in functions, examples or
>> vignettes.
>> >>> 3. Because it contains complementary functions.
>> >>>
>> >>> I don't think we really need to worry about 3: it should be
>> contained
>> >>> in 1 or 2, if reasonably complete examples are given.
>> >>>
>> >>> Case 1 is handled by Depends.
>> >>
>> >> I think there is an important distinction between a dependency needed
>> >> for the package to function and a dependency needed to demonstrate
>> >> said functionality via an example or vignette. The former is what
>> >> Depends is about, the latter is something else (Suggests).
>>
>> FrL> Sorry to join in late, I am at the Compstat conference and have
>> limited
>> FrL> email access. What Seth describes in the above paragraph is exactly
>> what I
>> FrL> had in mind when splitting the single Depends field we had into
>> Depends
>> FrL> and Suggests: Depends are a necessity to run the package, Suggests
>> is nice
>> FrL> to have but not necessary. If you know how to use a package you may
>> the
>> FrL> decide not to install a package that is only suggested, but
>>
>> FrL> * may not be interested to execute the examples,
>> FrL> * know that you never need the extra functionality
>> FrL> * ...
>>
>> FrL> so it should not be auto-installed unless you ask for
>> FrL> it (the default could also be the other way round, the
>> FrL> point is that it should be possible to have package foo
>> FrL> but not the packages it only suggests). On CRAN we
>> FrL> check with all suggestions to test all bits and pieces,
>> FrL> having an option in R CMD check to test only with
>> FrL> suggests may be nice, if there is use for it.
>>
>> Yes.
>> However, I see two (related) problems with the current 'Suggests'
>> and that's why I opened this thread proposing to have a
>> (what I now would want to simply call) 'canUse' :
>>
>> 1) For 'R CMD check' (and hence CRAN checking),
>>Packages in 'Suggests' must be require()able, and
>>hence all testing only happens *with* the suggested packages
>>being there, and not without.
>>
>> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>>the package authors suggest to also install the packages listed
>>there.
>>Now there are cases, I (as package author) want to show some
>>stuff, or even provide compatibility functionality for some
>>packages that are related to mine, but which I really do not ``suggest''
>>to also be installed, e.g., because the other packages do
>>similar stuff as mine, but I believe my package to be
>>superior. In such a case, I may, e.g., want to provide
>>functions for porting the other package classes to my package's.
>>
>> Duncan Murdoch has proposed to take care of "1)" by
>> still only use 'Suggests' but adding another option to 'R CMD
>> check', let's say --no-suggests which would run all the
>> checks without having the suggested packages available
>> --- something not quite easy to implement, BTW:
>> Imagine the typical windows users who (AFAICS) always only use
>> one library into which they install all packages.
>> How do you want the
>> if( require() ) {
>>...
>> }
>> clause *not* to be triggered in such a case ?
>
> I would expect require to return FALSE. This could be done by check
> installing a new version of require() (as it installs new T and F), or
> by the standard require() being modified to check a stop list before
> acting (I'd prefer this, because it would make it easier for developers
> to experiment with functions in different environments), or by playing
> around with the names of things in the library (probably not workable on
> Windows), etc.
>
> I think the default check behaviour on CRAN should be my middle case:
> test based on what is currently installed, don't require packages listed
> in Suggests to be installed. I'm not sure if that should be the default
> behaviour for R CMD check at the command line: as Kurt said, usually a
> developer wants to check all of the code.
>
>> I do agree quite a bit that such a '--no-suggests' option would
>> be very useful for 'R CMD check' -- in addition to my proposal.
>
> I think the other extreme (which I think is there now as
> _R_CHECK_FORCE_SUGGESTS_) is also important.
>
>> Further, I think "2)" above is not taken care of anyway.
>> After all th
Re: [Rd] 'CanMakeUseOf' field
On 8/30/2006 12:28 PM, Paul Gilbert wrote:
> Duncan Murdoch wrote:
>> On 8/30/2006 4:44 AM, Martin Maechler wrote:
"FrL" == friedrich leisch <[EMAIL PROTECTED]>
on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>>> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>> >>> I think we need an option to R CMD check rather than a new field in
>>> the
>>> >>> DESCRIPTION. Currently a package could be mentioned for any of
>>> these
>>> >>> reasons:
>>> >>>
>>> >>> 1. To make functions, examples or vignettes work
>>> >>> 2. To allow optional functionality in functions, examples or
>>> vignettes.
>>> >>> 3. Because it contains complementary functions.
>>> >>>
>>> >>> I don't think we really need to worry about 3: it should be
>>> contained
>>> >>> in 1 or 2, if reasonably complete examples are given.
>>> >>>
>>> >>> Case 1 is handled by Depends.
>>> >>
>>> >> I think there is an important distinction between a dependency needed
>>> >> for the package to function and a dependency needed to demonstrate
>>> >> said functionality via an example or vignette. The former is what
>>> >> Depends is about, the latter is something else (Suggests).
>>>
>>> FrL> Sorry to join in late, I am at the Compstat conference and have
>>> limited
>>> FrL> email access. What Seth describes in the above paragraph is
>>> exactly what I
>>> FrL> had in mind when splitting the single Depends field we had into
>>> Depends
>>> FrL> and Suggests: Depends are a necessity to run the package, Suggests
>>> is nice
>>> FrL> to have but not necessary. If you know how to use a package you
>>> may the
>>> FrL> decide not to install a package that is only suggested, but
>>>
>>> FrL> * may not be interested to execute the examples,
>>> FrL> * know that you never need the extra functionality
>>> FrL> * ...
>>>
>>> FrL> so it should not be auto-installed unless you ask for
>>> FrL> it (the default could also be the other way round, the
>>> FrL> point is that it should be possible to have package foo
>>> FrL> but not the packages it only suggests). On CRAN we
>>> FrL> check with all suggestions to test all bits and pieces,
>>> FrL> having an option in R CMD check to test only with
>>> FrL> suggests may be nice, if there is use for it.
>>>
>>> Yes.
>>> However, I see two (related) problems with the current 'Suggests'
>>> and that's why I opened this thread proposing to have a
>>> (what I now would want to simply call) 'canUse' :
>>>
>>> 1) For 'R CMD check' (and hence CRAN checking),
>>>Packages in 'Suggests' must be require()able, and
>>>hence all testing only happens *with* the suggested packages
>>>being there, and not without.
>>>
>>> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>>>the package authors suggest to also install the packages listed
>>>there.
>>>Now there are cases, I (as package author) want to show some
>>>stuff, or even provide compatibility functionality for some
>>>packages that are related to mine, but which I really do not ``suggest''
>>>to also be installed, e.g., because the other packages do
>>>similar stuff as mine, but I believe my package to be
>>>superior. In such a case, I may, e.g., want to provide
>>>functions for porting the other package classes to my package's.
>>>
>>> Duncan Murdoch has proposed to take care of "1)" by
>>> still only use 'Suggests' but adding another option to 'R CMD
>>> check', let's say --no-suggests which would run all the
>>> checks without having the suggested packages available
>>> --- something not quite easy to implement, BTW:
>>> Imagine the typical windows users who (AFAICS) always only use
>>> one library into which they install all packages.
>>> How do you want the
>>> if( require() ) {
>>>...
>>> }
>>> clause *not* to be triggered in such a case ?
>>
>> I would expect require to return FALSE. This could be done by check
>> installing a new version of require() (as it installs new T and F), or
>> by the standard require() being modified to check a stop list before
>> acting (I'd prefer this, because it would make it easier for developers
>> to experiment with functions in different environments), or by playing
>> around with the names of things in the library (probably not workable on
>> Windows), etc.
>>
>> I think the default check behaviour on CRAN should be my middle case:
>> test based on what is currently installed, don't require packages listed
>> in Suggests to be installed. I'm not sure if that should be the default
>> behaviour for R CMD check at the command line: as Kurt said, usually a
>> developer wants to check all of the code.
>>
>>> I do agree quite a bit that such a '--no-suggests' option would
>>> be very useful for 'R CMD check' -- in addition to my proposal.
>>
>> I think the other extreme (which
Re: [Rd] S4 Methods dispatch
[Cross-posting to BioC-devel to] Thank you for this. > The changes are internal but extensive. All packages that use S4 > methods and classes need to be reinstalled from source to use the new > version. Is there an easy way to detect if a package is using S4 or not? If so, I could scan my already installed libraries and call install.packages() on its S4 subset of packages. The alternative is to do install.packages() an all libraries (sic!). Bioconductor: maybe biocLite() could have such an update mechanism built in internally? If I miss to reinstall one S4 package, what should I expect? I assume there will be an error, but I just want to confirm that there is no risk of getting weird "results" but still a running program? Reinstallation is also required for all package that comes as Windows binaries, correct? Best Henrik On 8/30/06, John Chambers <[EMAIL PROTECTED]> wrote: > A revision of r-devel 2.4.0 is being committed today with changes to > method and class management. > > The changes are internal but extensive. All packages that use S4 > methods and classes need to be reinstalled from source to use the new > version. > > The main effects are to speed up method caching and dispatch, and to fix > some problems with selecting inherited methods. The new design is also > cleaner, so we can experiment more easily in the future with changes for > efficiency or semantics. > > The change will mostly be noticeable in attaching packages with many > methods. The CPU time for attaching package Matrix, for example, goes > down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5. > > The other major change is that now _all_ inherited methods are examined > and one of the closest matches is chosen. The old selection took the > first candidate found, so the current version is better defined, and > will also let us experiment with various tuning & strategies. > > There is a draft paper describing method selection at > http://developer.r-project.org/howMethodsWork.pdf > (It's a document in progress, so go back in a few days for a revised > version.) > > If a package uses inheritance for method selection with multiple > arguments, there may well be changes in behavior. We found examples in > both methods itself and in Matrix that needed attention. > > John > > __ > 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] S4 Methods dispatch
John Chambers wrote: > A revision of r-devel 2.4.0 is being committed today with changes to > method and class management. > > The changes are internal but extensive. All packages that use S4 > methods and classes need to be reinstalled from source to use the new > version. > A footnote on this. ALL packages need to be reinstalled--including stats4 in the R source. Otherwise that package will fail when used in the tests. I was bitten by this myself today. Advice from members of r-core more expert in the innards, suggests that the best thing to do is make clean in the directory where you are building R, if you have previously built R there, before making the new version of R. > The main effects are to speed up method caching and dispatch, and to fix > some problems with selecting inherited methods. The new design is also > cleaner, so we can experiment more easily in the future with changes for > efficiency or semantics. > > The change will mostly be noticeable in attaching packages with many > methods. The CPU time for attaching package Matrix, for example, goes > down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5. > > The other major change is that now _all_ inherited methods are examined > and one of the closest matches is chosen. The old selection took the > first candidate found, so the current version is better defined, and > will also let us experiment with various tuning & strategies. > > There is a draft paper describing method selection at > http://developer.r-project.org/howMethodsWork.pdf > (It's a document in progress, so go back in a few days for a revised > version.) > > If a package uses inheritance for method selection with multiple > arguments, there may well be changes in behavior. We found examples in > both methods itself and in Matrix that needed attention. > > John > > __ > 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] S4 Methods dispatch
"Henrik Bengtsson" <[EMAIL PROTECTED]> writes: > [Cross-posting to BioC-devel to] I'll answer here for now. > Is there an easy way to detect if a package is using S4 or not? If > so, I could scan my already installed libraries and call > install.packages() on its S4 subset of packages. The alternative is > to do install.packages() an all libraries (sic!). Bioconductor: maybe > biocLite() could have such an update mechanism built in internally? This really is only an issue for developers and those living on the bleeding edge. That is, when upgrading R, one generally reinstalls all packages anyhow (at least that is what I do). > If I miss to reinstall one S4 package, what should I expect? I assume > there will be an error, but I just want to confirm that there is no > risk of getting weird "results" but still a running program? Not sure, but in some testing I know that in at least _some_ cases, one does get an error message. > Reinstallation is also required for all package that comes as Windows > binaries, correct? But one has to reinstall binaries when upgrading R anyway. Unless I'm missing something, I would say this is a case where developers and those on the bleeding edge just have to bite the bullet and reinstall. As for identifying S4 using packages, I think it is the case that such packages will have one or more of the following: 1. methods package in Depends 2. methods package in Imports 3. import or importFrom methods in NAMESPACE 4. a call to setClass, setMethod, or setGeneric in R sources (harder to identify) Items 1 and 2 above would be easy to pull out of the return value of installed.packages(). Best, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 Methods dispatch
On Wed, 30 Aug 2006, Henrik Bengtsson wrote:
> [Cross-posting to BioC-devel to]
>
> Thank you for this.
>
> > The changes are internal but extensive. All packages that use S4
> > methods and classes need to be reinstalled from source to use the new
> > version.
>
> Is there an easy way to detect if a package is using S4 or not? If
Yes, look at the Depends field of the DESCRIPTION
a <- installed.packages()
aa <- as.vector(a[grep("methods", a[, "Depends"]), 1])
install.packages(aa)
If you want to install them in the same place as before, do this for each
library in turn.
I'd hold off for a few days if you can: some packages will not yet
reinstall.
> so, I could scan my already installed libraries and call
> install.packages() on its S4 subset of packages. The alternative is
> to do install.packages() an all libraries (sic!). Bioconductor: maybe
> biocLite() could have such an update mechanism built in internally?
>
> If I miss to reinstall one S4 package, what should I expect? I assume
> there will be an error, but I just want to confirm that there is no
> risk of getting weird "results" but still a running program?
>
> Reinstallation is also required for all package that comes as Windows
> binaries, correct?
Correct, and from source at that since Uwe is not yet building packages
under R-devel (and his '2.4' is really 2.3, as I understand it).
--
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] S4 Methods dispatch
Henrik Bengtsson wrote: > [Cross-posting to BioC-devel to] > > Thank you for this. > >> The changes are internal but extensive. All packages that use S4 >> methods and classes need to be reinstalled from source to use the new >> version. > > Is there an easy way to detect if a package is using S4 or not? If you have your package source in various directories under a single directory (which is how I usually work), then, from the directory above the package directories, the comand: grep "Depends:.*methods" */DESCRIPTION will pick up the packages that declare a dependency on methods. There may be cleaner techniques. > If > so, I could scan my already installed libraries and call > install.packages() on its S4 subset of packages. The alternative is > to do install.packages() an all libraries (sic!). Bioconductor: maybe > biocLite() could have such an update mechanism built in internally? > > If I miss to reinstall one S4 package, what should I expect? The typical symptom is a clutch of warning messages when you attach the package. The warnings try to mention that the package may need reinstallling, though sometimes the package name is misleading. > I assume > there will be an error, but I just want to confirm that there is no > risk of getting weird "results" but still a running program? > > Reinstallation is also required for all package that comes as Windows > binaries, correct? Anything that uses S4 methods will have out-of-date objects for class and method definitions. John > > Best > > Henrik > > On 8/30/06, John Chambers <[EMAIL PROTECTED]> wrote: >> A revision of r-devel 2.4.0 is being committed today with changes to >> method and class management. >> >> The changes are internal but extensive. All packages that use S4 >> methods and classes need to be reinstalled from source to use the new >> version. >> >> The main effects are to speed up method caching and dispatch, and to fix >> some problems with selecting inherited methods. The new design is also >> cleaner, so we can experiment more easily in the future with changes for >> efficiency or semantics. >> >> The change will mostly be noticeable in attaching packages with many >> methods. The CPU time for attaching package Matrix, for example, goes >> down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5. >> >> The other major change is that now _all_ inherited methods are examined >> and one of the closest matches is chosen. The old selection took the >> first candidate found, so the current version is better defined, and >> will also let us experiment with various tuning & strategies. >> >> There is a draft paper describing method selection at >> http://developer.r-project.org/howMethodsWork.pdf >> (It's a document in progress, so go back in a few days for a revised >> version.) >> >> If a package uses inheritance for method selection with multiple >> arguments, there may well be changes in behavior. We found examples in >> both methods itself and in Matrix that needed attention. >> >> John >> >> __ >> 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] S4 Methods dispatch
On 8/30/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Aug 2006, Henrik Bengtsson wrote:
>
> > [Cross-posting to BioC-devel to]
> >
> > Thank you for this.
> >
> > > The changes are internal but extensive. All packages that use S4
> > > methods and classes need to be reinstalled from source to use the new
> > > version.
> >
> > Is there an easy way to detect if a package is using S4 or not? If
>
> Yes, look at the Depends field of the DESCRIPTION
>
> a <- installed.packages()
> aa <- as.vector(a[grep("methods", a[, "Depends"]), 1])
> install.packages(aa)
I think it's more complicated than this. First of all, is it
mandatory for a package to be explicit about 'methods'? Second, there
are many packages that imports 'methods' implicitly via dependency of
other S4 packages, .e.g see many Bioconductor packages. Thus, for
this to work we have to build the dependency graph, and it have to
work across repositories.
One way would be to load packages (that are explicit about 'methods')
and do some investigation on them.
>From John Chambers updated post on this thread, it look like we should
reinstall all package to be on the safe side.
>
> If you want to install them in the same place as before, do this for each
> library in turn.
>
> I'd hold off for a few days if you can: some packages will not yet
> reinstall.
>
> > so, I could scan my already installed libraries and call
> > install.packages() on its S4 subset of packages. The alternative is
> > to do install.packages() an all libraries (sic!). Bioconductor: maybe
> > biocLite() could have such an update mechanism built in internally?
> >
> > If I miss to reinstall one S4 package, what should I expect? I assume
> > there will be an error, but I just want to confirm that there is no
> > risk of getting weird "results" but still a running program?
> >
> > Reinstallation is also required for all package that comes as Windows
> > binaries, correct?
>
> Correct, and from source at that since Uwe is not yet building packages
> under R-devel (and his '2.4' is really 2.3, as I understand it).
Ah, that last part is an EXTREMELY IMPORTANT PIECE OF INFORMATION,
related to this S4 update.
I predict that there will unfortunately be a few postings of people
being bitten by this. I can see how you run install/update.packages()
on a Windows machine and things stops working. Then there is no
repository to fall back to, and if you do not have the machinery for
installing from source on Windows it's going to be a mess.
It sound like that creating a copy of the (binary) package reprocitory
as is today would be the first precocious step to take. If problems
occur until Uwe gets his "2.4" up and running, at least this can be
used as a backup for people being bitten by the above.
I'm on Windows too, and at least I will make a local copy of what I've
got today and I will avoid doing install/update.packages() on
CRAN/Bioconductor until I know things are working. I will also keep
my current R-devel installation around, because that should work with
Uwe's current "2.3" rep, (I believe?).
/H
>
> --
> 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] S4 Methods dispatch
On 8/30/2006 1:35 PM, John Chambers wrote:
> Henrik Bengtsson wrote:
>> [Cross-posting to BioC-devel to]
>>
>> Thank you for this.
>>
>>> The changes are internal but extensive. All packages that use S4
>>> methods and classes need to be reinstalled from source to use the new
>>> version.
>>
>> Is there an easy way to detect if a package is using S4 or not?
>
> If you have your package source in various directories under a single
> directory (which is how I usually work), then, from the directory above
> the package directories, the comand:
> grep "Depends:.*methods" */DESCRIPTION
> will pick up the packages that declare a dependency on methods. There
> may be cleaner techniques.
This does the same within R:
> pkgs <- installed.packages()
> pkgs[grep("methods", pkgs[,"Depends"]),]
Duncan Murdoch
>> If
>> so, I could scan my already installed libraries and call
>> install.packages() on its S4 subset of packages. The alternative is
>> to do install.packages() an all libraries (sic!). Bioconductor: maybe
>> biocLite() could have such an update mechanism built in internally?
>>
>> If I miss to reinstall one S4 package, what should I expect?
>
> The typical symptom is a clutch of warning messages when you attach the
> package. The warnings try to mention that the package may need
> reinstallling, though sometimes the package name is misleading.
>
>> I assume
>> there will be an error, but I just want to confirm that there is no
>> risk of getting weird "results" but still a running program?
>>
>> Reinstallation is also required for all package that comes as Windows
>> binaries, correct?
> Anything that uses S4 methods will have out-of-date objects for class
> and method definitions.
>
> John
>>
>> Best
>>
>> Henrik
>>
>> On 8/30/06, John Chambers <[EMAIL PROTECTED]> wrote:
>>> A revision of r-devel 2.4.0 is being committed today with changes to
>>> method and class management.
>>>
>>> The changes are internal but extensive. All packages that use S4
>>> methods and classes need to be reinstalled from source to use the new
>>> version.
>>>
>>> The main effects are to speed up method caching and dispatch, and to fix
>>> some problems with selecting inherited methods. The new design is also
>>> cleaner, so we can experiment more easily in the future with changes for
>>> efficiency or semantics.
>>>
>>> The change will mostly be noticeable in attaching packages with many
>>> methods. The CPU time for attaching package Matrix, for example, goes
>>> down by about a factor of 7 compared to R 2.3.1, timed on a Mac G5.
>>>
>>> The other major change is that now _all_ inherited methods are examined
>>> and one of the closest matches is chosen. The old selection took the
>>> first candidate found, so the current version is better defined, and
>>> will also let us experiment with various tuning & strategies.
>>>
>>> There is a draft paper describing method selection at
>>> http://developer.r-project.org/howMethodsWork.pdf
>>> (It's a document in progress, so go back in a few days for a revised
>>> version.)
>>>
>>> If a package uses inheritance for method selection with multiple
>>> arguments, there may well be changes in behavior. We found examples in
>>> both methods itself and in Matrix that needed attention.
>>>
>>> John
>>>
>>> __
>>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch wrote:
> On 8/30/2006 12:28 PM, Paul Gilbert wrote:
>> Duncan Murdoch wrote:
>>> On 8/30/2006 4:44 AM, Martin Maechler wrote:
> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>> I think we need an option to R CMD check rather than a new
field in the
>>> DESCRIPTION. Currently a package could be mentioned for any
of these
>>> reasons:
>>> >>> 1. To make functions, examples or vignettes work
>>> 2. To allow optional functionality in functions, examples
or vignettes.
>>> 3. Because it contains complementary functions.
>>> >>> I don't think we really need to worry about 3: it
should be contained
>>> in 1 or 2, if reasonably complete examples are given.
>>> >>> Case 1 is handled by Depends.
>> >> I think there is an important distinction between a
dependency needed
>> for the package to function and a dependency needed to
demonstrate
>> said functionality via an example or vignette. The former is
what
>> Depends is about, the latter is something else (Suggests).
FrL> Sorry to join in late, I am at the Compstat conference and
have limited
FrL> email access. What Seth describes in the above paragraph is
exactly what I
FrL> had in mind when splitting the single Depends field we had
into Depends
FrL> and Suggests: Depends are a necessity to run the package,
Suggests is nice
FrL> to have but not necessary. If you know how to use a package
you may the
FrL> decide not to install a package that is only suggested, but
FrL> * may not be interested to execute the examples,
FrL> * know that you never need the extra functionality
FrL> * ...
FrL> so it should not be auto-installed unless you ask for
FrL> it (the default could also be the other way round, the
FrL> point is that it should be possible to have package foo
FrL> but not the packages it only suggests). On CRAN we
FrL> check with all suggestions to test all bits and pieces,
FrL> having an option in R CMD check to test only with
FrL> suggests may be nice, if there is use for it.
Yes.
However, I see two (related) problems with the current 'Suggests'
and that's why I opened this thread proposing to have a (what I now
would want to simply call) 'canUse' :
1) For 'R CMD check' (and hence CRAN checking),
Packages in 'Suggests' must be require()able, and
hence all testing only happens *with* the suggested packages
being there, and not without.
2) "Suggests" suggests to the human reader of DESCRIPTION that
the package authors suggest to also install the packages listed
there.
Now there are cases, I (as package author) want to show some
stuff, or even provide compatibility functionality for some
packages that are related to mine, but which I really do not
``suggest''
to also be installed, e.g., because the other packages do
similar stuff as mine, but I believe my package to be
superior. In such a case, I may, e.g., want to provide
functions for porting the other package classes to my package's.
Duncan Murdoch has proposed to take care of "1)" by
still only use 'Suggests' but adding another option to 'R CMD
check', let's say --no-suggests which would run all the
checks without having the suggested packages available ---
something not quite easy to implement, BTW:
Imagine the typical windows users who (AFAICS) always only use
one library into which they install all packages.
How do you want the if( require() ) {
...
}
clause *not* to be triggered in such a case ?
>>>
>>> I would expect require to return FALSE. This could be done by check
>>> installing a new version of require() (as it installs new T and F),
>>> or by the standard require() being modified to check a stop list
>>> before acting (I'd prefer this, because it would make it easier for
>>> developers to experiment with functions in different environments),
>>> or by playing around with the names of things in the library
>>> (probably not workable on Windows), etc.
>>>
>>> I think the default check behaviour on CRAN should be my middle case:
>>> test based on what is currently installed, don't require packages
>>> listed in Suggests to be installed. I'm not sure if that should be
>>> the default behaviour for R CMD check at the command line: as Kurt
>>> said, usually a developer wants to check all of the code.
>>>
I do agree quite a bit that such a '--no-suggests' opt
Re: [Rd] S4 Methods dispatch
"Henrik Bengtsson" <[EMAIL PROTECTED]> writes: > I think it's more complicated than this. First of all, is it > mandatory for a package to be explicit about 'methods'? Second, there > are many packages that imports 'methods' implicitly via dependency of > other S4 packages, .e.g see many Bioconductor packages. Thus, for > this to work we have to build the dependency graph, and it have to > work across repositories. [As I already posted, I don't think this is worth the effort, better to just reinstall.] But this coincides with work I've been doing on tools for package dependency graphs. If you're curious, read on... allDeps <- makeDepGraph(biocReposList(), type="source", keep.builtin=TRUE, dosize=FALSE) allDepsOnMe <- reverseEdgeDirections(allDeps) needsMethods <- dijkstra.sp(allDepsOnMe, start="methods") needsMethods <- needsMethods$distance[is.finite(needsMethods$distance)] length(needsMethods) [1] 514 table(needsMethods) needsMethods 0 1 2 3 1 130 118 265 I won't spam the mailing list with the package names, but am happy to make them available if anyone would really find it useful. Bw, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion for read.table()
First, I compliment you all for such a useful project as R. Suggestion: If read.table() could take input from a character string, then one could write raw= " x y z 1 2 3 4 5 6 " df = read.table(raw,head=TRUE) Of course, one can cat() to write raw into a temporary file, and read.table() from that file. However, direct reading might be a good option? Hope this is useful. Cordially Giles Crane [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/30/2006 2:13 PM, Paul Gilbert wrote:
>
> Duncan Murdoch wrote:
>> On 8/30/2006 12:28 PM, Paul Gilbert wrote:
>>> Duncan Murdoch wrote:
On 8/30/2006 4:44 AM, Martin Maechler wrote:
>> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
>> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
> >>> I think we need an option to R CMD check rather than a new
> field in the
> >>> DESCRIPTION. Currently a package could be mentioned for any
> of these
> >>> reasons:
> >>> >>> 1. To make functions, examples or vignettes work
> >>> 2. To allow optional functionality in functions, examples
> or vignettes.
> >>> 3. Because it contains complementary functions.
> >>> >>> I don't think we really need to worry about 3: it
> should be contained
> >>> in 1 or 2, if reasonably complete examples are given.
> >>> >>> Case 1 is handled by Depends.
> >> >> I think there is an important distinction between a
> dependency needed
> >> for the package to function and a dependency needed to
> demonstrate
> >> said functionality via an example or vignette. The former is
> what
> >> Depends is about, the latter is something else (Suggests).
>
> FrL> Sorry to join in late, I am at the Compstat conference and
> have limited
> FrL> email access. What Seth describes in the above paragraph is
> exactly what I
> FrL> had in mind when splitting the single Depends field we had
> into Depends
> FrL> and Suggests: Depends are a necessity to run the package,
> Suggests is nice
> FrL> to have but not necessary. If you know how to use a package
> you may the
> FrL> decide not to install a package that is only suggested, but
>
> FrL> * may not be interested to execute the examples,
> FrL> * know that you never need the extra functionality
> FrL> * ...
>
> FrL> so it should not be auto-installed unless you ask for
> FrL> it (the default could also be the other way round, the
> FrL> point is that it should be possible to have package foo
> FrL> but not the packages it only suggests). On CRAN we
> FrL> check with all suggestions to test all bits and pieces,
> FrL> having an option in R CMD check to test only with
> FrL> suggests may be nice, if there is use for it.
>
> Yes.
> However, I see two (related) problems with the current 'Suggests'
> and that's why I opened this thread proposing to have a (what I now
> would want to simply call) 'canUse' :
>
> 1) For 'R CMD check' (and hence CRAN checking),
>Packages in 'Suggests' must be require()able, and
>hence all testing only happens *with* the suggested packages
>being there, and not without.
>
> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>the package authors suggest to also install the packages listed
>there.
>Now there are cases, I (as package author) want to show some
>stuff, or even provide compatibility functionality for some
>packages that are related to mine, but which I really do not
> ``suggest''
>to also be installed, e.g., because the other packages do
>similar stuff as mine, but I believe my package to be
>superior. In such a case, I may, e.g., want to provide
> functions for porting the other package classes to my package's.
>
> Duncan Murdoch has proposed to take care of "1)" by
> still only use 'Suggests' but adding another option to 'R CMD
> check', let's say --no-suggests which would run all the
> checks without having the suggested packages available ---
> something not quite easy to implement, BTW:
> Imagine the typical windows users who (AFAICS) always only use
> one library into which they install all packages.
> How do you want the if( require() ) {
>...
> }
> clause *not* to be triggered in such a case ?
I would expect require to return FALSE. This could be done by check
installing a new version of require() (as it installs new T and F),
or by the standard require() being modified to check a stop list
before acting (I'd prefer this, because it would make it easier for
developers to experiment with functions in different environments),
or by playing around with the names of things in the library
(probably not workable on Windows), etc.
I think the default check behaviour on CRAN should be my middle case:
test based on what is currently installed, don't require packages
listed in Suggests to be installed. I'm not sure if that should be
the default behaviour for R CMD check at the command
Re: [Rd] Suggestion for read.table()
On Wed, 30 Aug 2006, [EMAIL PROTECTED] wrote: > First, I compliment you all > for such a useful project as R. > > Suggestion: If read.table() could > take input from a character string, > then one could write > > raw= > " x y z >1 2 3 >4 5 6 > " > df = read.table(raw,head=TRUE) 'raw' is the name of a function in R, so not a good choice. > Of course, one can > cat() to write raw into a > temporary file, > and read.table() from that file. Yes, we have anonymous file connections for that. > However, direct reading might be a good option? See ?textConnection for how to do this. inp <- " x y z 1 2 3 4 5 6 " read.table(textConnection(inp), header=TRUE) The most common case is wanting to paste in, and we have "clipboard" for that (at least on Windows on X11: it would be a nice addition on Aqua). -- 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] Suggestion for read.table()
Try this: > raw= + " x y z + 1 2 3 + 4 5 6 + " > read.table(textConnection(raw), header = TRUE) x y z 1 1 2 3 2 4 5 6 On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > First, I compliment you all > for such a useful project as R. > > Suggestion: If read.table() could > take input from a character string, > then one could write > > raw= > " x y z > 1 2 3 > 4 5 6 > " > df = read.table(raw,head=TRUE) > > Of course, one can > cat() to write raw into a > temporary file, > and read.table() from that file. > However, direct reading > might be a good option? > > Hope this is useful. > Cordially > Giles Crane > [EMAIL PROTECTED] > > __ > 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] Suggestion for read.table()
Hi Giles, x = "x y z\n1 2 3\n4 5 6" res = read.table(textConnection(x), header=TRUE) will do. See also http://cran.r-project.org/doc/manuals/R-data.html Best wishes Wolfgang Huber EMBL-EBI, Cambridge UK [EMAIL PROTECTED] wrote: > First, I compliment you all > for such a useful project as R. > > Suggestion: If read.table() could > take input from a character string, > then one could write > > raw= > " x y z >1 2 3 >4 5 6 > " > df = read.table(raw,head=TRUE) > > Of course, one can > cat() to write raw into a > temporary file, > and read.table() from that file. > However, direct reading > might be a good option? > > Hope this is useful. > Cordially > Giles Crane > [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] make test-Specific?
Hello! In Writing R Extensions manual, section "Testing R code"[1] says: "be careful to check if make test-Specific or particularly, cd tests; make no-segfault.Rout" Actually, make test-Specific also needs "cd tests;" in front. [1]http://cran.r-project.org/doc/manuals/R-exts.html#Testing-R-code -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Summary() fails after use of na.action="na.exclude" in lm() (PR#9191)
Hello! I have already reported on this behaviour at [1] and now I have checked the same example on r-devel and the problem is still there. Thomas Lumley inidicated problem [2]. Example: n <- 50 x <- runif(n=n) y1 <- 2 * x + rnorm(n=n) y2 <- 5 * x + rnorm(n=n) y2[sample(1:n, size=5)] <- NA y <- cbind(y1, y2) ## Goes ok here fit <- lm(y1 ~ 1, na.action="na.exclude") summary(fit) ## And here fit <- lm(y2 ~ 1, na.action="na.exclude") summary(fit) ## But fails if we use matrix of response variables fit <- lm(y ~ 1, na.action="na.exclude") summary(fit) Response y1 : Call: lm(formula = y1 ~ 1, na.action = "na.exclude") Residuals: Error in quantile.default(resid) : missing values and NaN's not allowed if 'na.rm' is FALSE [1]http://tolstoy.newcastle.edu.au/R/devel/06/07/6187.html [2]http://tolstoy.newcastle.edu.au/R/devel/06/07/6203.html --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = Under development (unstable) major = 2 minor = 4.0 year = 2006 month = 08 day = 30 svn rev = 39022 language = R version.string = R version 2.4.0 Under development (unstable) (2006-08-30 r39022) Locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base -- Lep pozdrav / With regards, Gregor Gorjanc -- University of Ljubljana PhD student Biotechnical Faculty Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si SI-1230 Domzale tel: +386 (0)1 72 17 861 Slovenia, Europefax: +386 (0)1 72 17 888 -- "One must learn by doing the thing; for though you think you know it, you have no certainty until you try." Sophocles ~ 450 B.C. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wish: keep names in mapply() result
Hello!
I have noticed that mapply() drops names in R 2.3.1 as well as in
r-devel. Here is a simple example:
l <- list(a=1, b=2)
k <- list(1)
mapply(FUN="+", l, k)
[1] 2 3
mapply(FUN="+", l, k, SIMPLIFY=FALSE)
[[1]]
[1] 2
[[2]]
[1] 3
Help page does not indicate that this should happen. Argument USE.NAMES
does not have any effect here as it used only in a bit special
situation: "If the first ... argument is character and the result does
not already have names, use it as the names." But result is always
without names as shown above. Did I miss any peculiarities?
This is not consistent with lapply, which keeps names i.e.
lapply(l, "+", 1)
$a
[1] 2
$b
[1] 3
I have attached and copied (at the end) patch proposal against SVN that
adds names back to the result if x had it (only R as my C is ...). This
way it would also be consistent with lapply. make check-all seems to be
happy with changes. Now we get:
mapply(FUN="+", l, k)
a b
2 3
mapply(FUN="+", l, k, SIMPLIFY=FALSE)
$a
[1] 2
$b
[1] 3
And if we had "character" (with some variations) for first ... then:
l <- list(a="1", b="2")
mapply(FUN="paste", l, k)
a b
"1 1" "2 1"
l <- list("1", "2")
mapply(FUN="paste", l, k)
[1] "1 1" "2 1"
l <- c("1", "2")
mapply(FUN="paste", l, k)
1 2
"1 1" "2 1"
Index: src/library/base/R/mapply.R
===
--- src/library/base/R/mapply.R (revision 39024)
+++ src/library/base/R/mapply.R (working copy)
@@ -3,8 +3,16 @@
FUN <- match.fun(FUN)
dots <- list(...)
+if(!is.null(names(dots[[1]]))) {
+isNamed <- TRUE
+namesX <- names(dots[[1]])
+} else {
+isNamed <- FALSE
+}
+
answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
PACKAGE="base")
+if(isNamed) names(answer) <- namesX
if (USE.NAMES && length(dots) && is.character(dots[[1]]) &&
is.null(names(answer))) names(answer) <- dots[[1]]
@@ -47,4 +55,4 @@
}
formals(FUNV) <- formals(FUN)
FUNV
-}
\ No newline at end of file
+}
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Faculty
Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale tel: +386 (0)1 72 17 861
Slovenia, Europefax: +386 (0)1 72 17 888
--
"One must learn by doing the thing; for though you think you know it,
you have no certainty until you try." Sophocles ~ 450 B.C.
--
Index: src/library/base/R/mapply.R
===
--- src/library/base/R/mapply.R (revision 39024)
+++ src/library/base/R/mapply.R (working copy)
@@ -3,8 +3,16 @@
FUN <- match.fun(FUN)
dots <- list(...)
+if(!is.null(names(dots[[1]]))) {
+isNamed <- TRUE
+namesX <- names(dots[[1]])
+} else {
+isNamed <- FALSE
+}
+
answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
PACKAGE="base")
+if(isNamed) names(answer) <- namesX
if (USE.NAMES && length(dots) && is.character(dots[[1]]) &&
is.null(names(answer))) names(answer) <- dots[[1]]
@@ -47,4 +55,4 @@
}
formals(FUNV) <- formals(FUN)
FUNV
-}
\ No newline at end of file
+}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish: keep names in mapply() result
Gregor:
Works for me on 2.3.0:
> mapply(function(x,y,z) paste(y,z), letters,as.list(LETTERS),as.list(1:26))[
> 1:5 ]
a b c d e
"A 1" "B 2" "C 3" "D 4" "E 5"
> mapply(function(x,y,z) paste(x,y,z), letters,as.list(LETTERS),as.list(1:26))[
> 1:5 ]
a b c d e
"a A 1" "b B 2" "c C 3" "d D 4" "e E 5"
>
but this does not yield names:
> mapply(function(x,y,z) paste(x,y,z),
> as.list(letters),as.list(LETTERS),as.list(1:26))[ 1:5 ]
[1] "a A 1" "b B 2" "c C 3" "d D 4" "e E 5"
Perhaps the help page would be clearer if it said:
USE.NAMES: If the first ... argument is a character ***vector*** and the result
doesn't already have names, use it as the names
Chuck
On Thu, 31 Aug 2006, Gregor Gorjanc wrote:
> Hello!
>
> I have noticed that mapply() drops names in R 2.3.1 as well as in
> r-devel. Here is a simple example:
>
> l <- list(a=1, b=2)
> k <- list(1)
> mapply(FUN="+", l, k)
> [1] 2 3
> mapply(FUN="+", l, k, SIMPLIFY=FALSE)
> [[1]]
> [1] 2
>
> [[2]]
> [1] 3
>
> Help page does not indicate that this should happen. Argument USE.NAMES
> does not have any effect here as it used only in a bit special
> situation: "If the first ... argument is character and the result does
> not already have names, use it as the names." But result is always
> without names as shown above. Did I miss any peculiarities?
>
> This is not consistent with lapply, which keeps names i.e.
>
> lapply(l, "+", 1)
> $a
> [1] 2
>
> $b
> [1] 3
>
> I have attached and copied (at the end) patch proposal against SVN that
> adds names back to the result if x had it (only R as my C is ...). This
> way it would also be consistent with lapply. make check-all seems to be
> happy with changes. Now we get:
>
> mapply(FUN="+", l, k)
> a b
> 2 3
>
> mapply(FUN="+", l, k, SIMPLIFY=FALSE)
> $a
> [1] 2
>
> $b
> [1] 3
>
> And if we had "character" (with some variations) for first ... then:
>
> l <- list(a="1", b="2")
> mapply(FUN="paste", l, k)
>a b
> "1 1" "2 1"
>
> l <- list("1", "2")
> mapply(FUN="paste", l, k)
> [1] "1 1" "2 1"
>
> l <- c("1", "2")
> mapply(FUN="paste", l, k)
>1 2
> "1 1" "2 1"
>
> Index: src/library/base/R/mapply.R
> ===
> --- src/library/base/R/mapply.R (revision 39024)
> +++ src/library/base/R/mapply.R (working copy)
> @@ -3,8 +3,16 @@
> FUN <- match.fun(FUN)
> dots <- list(...)
>
> +if(!is.null(names(dots[[1]]))) {
> +isNamed <- TRUE
> +namesX <- names(dots[[1]])
> +} else {
> +isNamed <- FALSE
> +}
> +
> answer<-.Call("do_mapply", FUN, dots, MoreArgs, environment(),
> PACKAGE="base")
> +if(isNamed) names(answer) <- namesX
>
> if (USE.NAMES && length(dots) && is.character(dots[[1]]) &&
> is.null(names(answer))) names(answer) <- dots[[1]]
> @@ -47,4 +55,4 @@
> }
> formals(FUNV) <- formals(FUN)
> FUNV
> -}
> \ No newline at end of file
> +}
>
> --
> Lep pozdrav / With regards,
>Gregor Gorjanc
>
> --
> University of Ljubljana PhD student
> Biotechnical Faculty
> Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
> Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
>
> SI-1230 Domzale tel: +386 (0)1 72 17 861
> Slovenia, Europefax: +386 (0)1 72 17 888
>
> --
> "One must learn by doing the thing; for though you think you know it,
> you have no certainty until you try." Sophocles ~ 450 B.C.
> --
>
Charles C. Berry(858) 534-2098
Dept of Family/Preventive Medicine
E mailto:[EMAIL PROTECTED] UC San Diego
http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
