Re: [Rd] Problem installing from source: no CONTENTS files
This will only happen if you installed R without HTML help and then
install a package *with* HTML help *and* do so into a non-standard
directory. That seems an arcane thing to do: why do you want HTML help
for some packages and not others? You will end up with a partially
functional system.
The fix is simple: put '-' at the beginning of that line (after the tab)
in MakePkg. I've put a more complete solution in R-devel.
On Mon, 9 Jan 2006 [EMAIL PROTECTED] wrote:
> I've just had the error below while trying to install a package from
> source under R2.2.1 and Windows XP. I recall encountering this
> sporadically in the past. It is a pretty confusing message and took me
> quite some time to figure out; I've seen queries about it on the R site
> search, but couldn't find a reply.
I don't believe those are the same thing.
> There's an attempted diagnosis and
> suggested cure below.
>
> D:\r2.0\debug>rcmd INSTALL --library=d:/rpackages/r2.2.1 --docs=normal
> debug
>
> -- Making package debug
> <>
> installing indices
> cat: C:/R/RW2021/library/*/CONTENTS: No such file or directory
>
> What I think is happening is this. Because I installed R from binary
> *without* HTML help, no CONTENTS files are created for the packages.
> When running RCMD INSTALL, this causes an error in the MakePkg file (in
> src/gnuwin32 on my machine), in the "indices" section at the line
> starting @$(CAT) below. Commenting out the CAT line seems to work fine,
> in that installation proceeds OK, and regular non-HTML help and
> help.search are available for the package. The comment two lines up
> suggests that the behaviour is a bug; maybe a TRY-style wrapper could be
> used? If not, a different error message would be handy.
The error message is completely informative: why would you want to change
it?
> I don't understand enough about makefiles to suggest a patch,
> unfortunately.
A good learning project for you?
>
> indices:
> @$(ECHO) " installing indices"
> @$(ECHO) "invisible(.libPaths(c(.Library,\"$(RLIB)\",
> .libPaths(; tools:::.install_package_indices('.', '"$(DPKG)"')" | \
> R_DEFAULT_PACKAGES=NULL LC_COLLATE=C R_OSTYPE=windows $(REXE)
>> /dev/null
> # need not have HTML installed when building packages
> @$(MKDIR) -p $(RHOME)/doc/html/search
> @$(CAT) $(RHOME)/library/*/CONTENTS >
> $(RHOME)/doc/html/search/index.txt
>
>
> Mark Bravington
> CSIRO Mathematical & Information Sciences
> Marine Laboratory
> Castray Esplanade
> Hobart 7001
> TAS
>
> ph (+61) 3 6232 5118
> fax (+61) 3 6232 5012
> mob (+61) 438 315 623
>
> __
> 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
[Rd] R plot display problem under windows when using python rpy module.
Dear list, Rpy is a python module that provides python interface to R. The following simple commands >>> from rpy import * >>> r.plot(0) is supposed to create a window that displays the result of plot(0). However, we observe that 1. Under *nix, rpy+R+python work as expected 2. Under windows, python + pythonWin32 (a python GUI provided by the pywin32 module), work as expected 3. Under windows, if we run the commands from command line or IDLE (a simple python IDE), a window will be created, but the figure will not be drawn. Then, if we run r.plot(2), the result of plot(0) will be drawn. plot(2) will be displayed when the next drawing command is executed. Since R works well in most cases, I do not think this is a R problem. However, can anyone tell me what *might* block the figures from being displayed? In other word, what might PythonWin have provided to enable correct rendering of the figures? If I have to trace to the sources, what portion of the R code should I have a look at? (It is good that python/R/rpy are all open source). Many thanks in advance. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R plot display problem under windows when using python rpy module.
How is Rpy calling R? Presumably R is running single-threaded, and the problem is likely to be that Rpy is using blocking I/O on the R process and hence blocking the GUI callbacks that drive the window. The not-so-simple answer is not to do it that way. It might be well sufficient to turn windows() buffering off -- see its help page. On Mon, 9 Jan 2006, Bo Peng wrote: > Dear list, > > Rpy is a python module that provides python interface to R. The > following simple commands > from rpy import * r.plot(0) > > is supposed to create a window that displays the result of plot(0). > > However, we observe that > 1. Under *nix, rpy+R+python work as expected > 2. Under windows, python + pythonWin32 (a python GUI provided by the > pywin32 module), work as expected > 3. Under windows, if we run the commands from command line or IDLE (a > simple python IDE), a window will be created, but the figure will not > be drawn. Then, if we run r.plot(2), the result of plot(0) will be > drawn. plot(2) will be displayed when the next drawing command is > executed. > > Since R works well in most cases, I do not think this is a R problem. > However, can anyone tell me what *might* block the figures from being > displayed? In other word, what might PythonWin have provided to enable > correct rendering of the figures? If I have to trace to the sources, > what portion of the R code should I have a look at? (It is good that > python/R/rpy are all open source). > > Many thanks in advance. > Bo > > __ > 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] R plot display problem under windows when using python rpy module.
On 1/9/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > How is Rpy calling R? Presumably R is running single-threaded, and the > problem is likely to be that Rpy is using blocking I/O on the R process > and hence blocking the GUI callbacks that drive the window. > > The not-so-simple answer is not to do it that way. It might be well > sufficient to turn windows() buffering off -- see its help page. Using >>> from rpy import * >>> r.options(windowsBuffered=False) >>> r.plot(0) solves the problem. Thank you very much! I will suggest that rpy developers address this problem. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R plot display problem under windows when using python rpy module.
Hi, (off topic slightly, and a slight flame-bait...). I don't have an answer or clue to your question, but I have played with PSPython briefly and it did work somewhat for me (and I have not heard of rpy until reading this through r-devel), and I was wondering what is the difference between rpy and RSPython. According to the rpy page: = This code is inspired by RSPython from the Omegahat project. The main goals of RPy are: * to have a very robust interface for using R from Python * the interface should be as transparent and easy to use as possible * it should be usable for real scientific and statistical computations = But "a very robust interface" is self-proclaimed and unsubstantiated; "transparent", "easy to use", "usable for real scientific..." are subjective, so what it amounts to is a case of "not-invented-here" symptom (i.e. wheels...). This might be flame-bait... but since I have used PSPython very very briefly and I don't think it suffers from the above 3 (and even if it does, it is open-source, one can always add/modify/patch without starting new), I do wonder... So I have a question for you - why rpy instead of RSPython? Have you tried both, and can you give a comparison of pros and cons? In fact, the most obvious superficial difference I can see is that RSPython is written by an R-biased person (it uses "R CMD build"), where as rpy is written by a Python-biased person (it builds with "python setup.py ...")... there is nothing wrong with having a bias, but the goals listed imply that it might be "better" in those areas... which may or may not be true. (To answer one question you might have, I was trying to invoke Python code from inside R and was doing it the opposite direction from you). HTL Bo Peng wrote: > Dear list, > > Rpy is a python module that provides python interface to R. The > following simple commands > > from rpy import * r.plot(0) > > > is supposed to create a window that displays the result of plot(0). > > However, we observe that > 1. Under *nix, rpy+R+python work as expected > 2. Under windows, python + pythonWin32 (a python GUI provided by the > pywin32 module), work as expected > 3. Under windows, if we run the commands from command line or IDLE (a > simple python IDE), a window will be created, but the figure will not > be drawn. Then, if we run r.plot(2), the result of plot(0) will be > drawn. plot(2) will be displayed when the next drawing command is > executed. > > Since R works well in most cases, I do not think this is a R problem. > However, can anyone tell me what *might* block the figures from being > displayed? In other word, what might PythonWin have provided to enable > correct rendering of the figures? If I have to trace to the sources, > what portion of the R code should I have a look at? (It is good that > python/R/rpy are all open source). > > Many thanks in advance. > Bo > > __ > 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] R plot display problem under windows when using python rpy module.
> I was wondering
> what is the difference between rpy and RSPython.
The main difference is that rpy does one-way communication, is simpler
than RSPython, than is easier to use.
> So I have a question for you - why rpy instead of RSPython? Have you
> tried both, and can you give a comparison of pros and cons?
I am not an expert on RSPython. I tried RSPython and rpy and chose rpy
for the following reasons:
1. rpy is in active maintenance. As you can see from rpy webpage, rpy
supports all versions of R till 2.2.1, python 2.4 and provides binary
installers like rpy-0.4.6-R-2.0.0-to-2.2.1-.xxx . On the contrary,
a windows installer for RSPython is for R-1.4.0, python 2.2.0.
2. RSPython uses mainly its RS.call function. This is troublesome and
is the main reason why I use rpy. For example,
in RSPython:
RS.call('rnorn', 10)
in rpy:
r.rnorm(10)
RSPython does provide similar usage now (maybe after I became a rpy user) but
RSPython:
from RS import R
R.rnorm(10) # works
R.dev.off() # does not work
Rpy solves this problem by (and the mechanism is clearly described in
the rpy manual):
from rpy import *
r.rnorm(10)
r.dev_off()
rpy also provides
r('''arbitrary R piece of code''')
which is immensely useful to run big trunk of R code.
rpy also claims that the performance of rpy is better but I have no
comparison data here.
> there is nothing wrong with having a bias,
> but the goals listed imply that it might be "better" in those areas...
> which may or may not be true.
I agree.
> (To answer one question you might have, I was trying to invoke Python
> code from inside R and was doing it the opposite direction from you).
Exactly. We are doing different things so while you have to use
RSPython, I have a choice between RSPython and rpy. In my case, all
the real computations are done in C/C++, wrapped by Python. I could
have wrapped my C/C++ code in R but R is not good at wrapping C++
class hierarchy because of the different OOP mechanisms. When I need
the statistical analysis and plotting capacity of R, I use rpy.
As a matter of fact, since Python is a powerful programming language
than can handle string, text file etc better than R, I usually prepare
my data in python and pass them to R using rpy.
Cheers,
Bo
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R plot display problem under windows when using python rpy module.
Thanks a lot for the comment and discussion. A few of mine below.
Bo Peng wrote:
> The main difference is that rpy does one-way communication, is simpler
> than RSPython, than is easier to use.
>
>
> I am not an expert on RSPython. I tried RSPython and rpy and chose rpy
> for the following reasons:
>
> 1. rpy is in active maintenance. As you can see from rpy webpage, rpy
> supports all versions of R till 2.2.1, python 2.4 and provides binary
> installers like rpy-0.4.6-R-2.0.0-to-2.2.1-.xxx . On the contrary,
> a windows installer for RSPython is for R-1.4.0, python 2.2.0.
I think my original comment regarding not-invented-here still applies -
it is a shame that much of the omegahat project is defunc, but it
doesn't mean that somebody interested in a particular orphaned project
can't take it over or fork it or enhance on top. I suspect a small part
of simpler/easier comes from it being smaller and younger, which is
exactly why one should think carefully about the "wheel"...
>
> 2. RSPython uses mainly its RS.call function. This is troublesome and
> is the main reason why I use rpy. For example,
>
> in RSPython:
> RS.call('rnorn', 10)
> in rpy:
> r.rnorm(10)
>
> RSPython does provide similar usage now (maybe after I became a rpy user) but
> RSPython:
> from RS import R
> R.rnorm(10) # works
> R.dev.off() # does not work
Maybe " R.dev("off") " ? Wild-guess here.
>
> Rpy solves this problem by (and the mechanism is clearly described in
> the rpy manual):
> from rpy import *
> r.rnorm(10)
> r.dev_off()
>
> rpy also provides
> r('''arbitrary R piece of code''')
> which is immensely useful to run big trunk of R code.
It might be RS.eval("...")? Again wild-guess here.
The "RS.call('routine', parameter)" syntax is actually how interpreted R
code interacts with compiled C routines in much of R itself.
I think this difference is very much about which language one is more at
home with.
(My background is actually somewhat stronger with Python than R, and
I was trying to learn R's C interfaces by looking at how R
interacts with more familiar languages like Perl/Python/Java)
>
> Exactly. We are doing different things so while you have to use
> RSPython, I have a choice between RSPython and rpy. In my case, all
> the real computations are done in C/C++, wrapped by Python. I could
> have wrapped my C/C++ code in R but R is not good at wrapping C++
> class hierarchy because of the different OOP mechanisms. When I need
> the statistical analysis and plotting capacity of R, I use rpy.
That's correct - C++ together with R is quite painful, and I can imagine
C++/Python being easier. (C++/R I have a little 1st hand experience
with, and I don't for C++/Python).
> As a matter of fact, since Python is a powerful programming language
> than can handle string, text file etc better than R, I usually prepare
> my data in python and pass them to R using rpy.
Thanks. That's useful to know.
HTL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(numeric(0)) surprise
I'm a little confused. I understand that numeric(0) means an empty
numeric vector, not the number 0 expressed as numeric. As it is now,
prod(numeric(0)) generates something -- a vector of length 1
containing the number 1 -- from nothing. I would have expected
prod(numeric(0)) ==> numeric(0)
this is consistent with
numeric(0) ==> numeric(0)
numeric(0) * 1 ==> numeric(0)
cumprod(numeric(0)) ==> numeric(0)
and, because concatenation occus before function evaluation,
prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
I would expect sum() to behave the same way, e.g., sum(numeric(0)) ==>
numeric(0). From below,
> consider exp(sum(log(numeric(0 ... ?)
> >>
> >> That's a fairly standard mathematical convention, which
> >> is presumably why sum and prod work that way.
> >>
> >> Duncan Murdoch
I would have expected numeric(0) as the result (numeric(0) is the
result from log(numeric(0)), etc).
Martin (Morgan)
Martin Maechler <[EMAIL PROTECTED]> writes:
>> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
>> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
>
> Ben> Duncan Murdoch wrote:
> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
> >>
> >>> It surprised me that prod(numeric(0)) is 1. I guess if
> >>> you say (operation(nothing) == identity element) this
> >>> makes sense, but ??
> >>
> >>
> >> What value were you expecting, or were you expecting an
> >> error? I can't think how any other value could be
> >> justified, and throwing an error would make a lot of
> >> formulas more complicated.
> >>
> >>>
> >>
> consider exp(sum(log(numeric(0 ... ?)
> >>
> >> That's a fairly standard mathematical convention, which
> >> is presumably why sum and prod work that way.
> >>
> >> Duncan Murdoch
>
> Ben>OK. I guess I was expecting NaN/NA (as opposed to
> Ben> an error), but I take the "this makes everything else
> Ben> more complicated" point. Should this be documented or
> Ben> is it just too obvious ... ? (Funny -- I'm willing to
> Ben> take gamma(1)==1 without any argument or suggestion
> Ben> that it should be documented ...)
>
> see? so it looks to me as if you have finally convinced
> yourself that '1' is the most reasonable result.. ;-)
>
> Anyway, I've added a sentence to help(prod) {which matches
> the sentence in help(sum), BTW}.
>
> Martin
>
> __
> 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] prod(numeric(0)) surprise
On 1/9/2006 12:40 PM, Martin Morgan wrote:
> I'm a little confused. I understand that numeric(0) means an empty
> numeric vector, not the number 0 expressed as numeric. As it is now,
> prod(numeric(0)) generates something -- a vector of length 1
> containing the number 1 -- from nothing. I would have expected
>
> prod(numeric(0)) ==> numeric(0)
>
> this is consistent with
>
> numeric(0) ==> numeric(0)
> numeric(0) * 1 ==> numeric(0)
> cumprod(numeric(0)) ==> numeric(0)
>
> and, because concatenation occus before function evaluation,
>
> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
>
> I would expect sum() to behave the same way, e.g., sum(numeric(0)) ==>
> numeric(0). From below,
>
I think the code below works as I'd expect. Would you really like the
last answer to be numeric(0)?
> x <- 1:10
> sum(x)
[1] 55
> sum(x[x>5])
[1] 40
> sum(x[x>10])
[1] 0
Duncan Murdoch
>> consider exp(sum(log(numeric(0 ... ?)
>> >>
>> >> That's a fairly standard mathematical convention, which
>> >> is presumably why sum and prod work that way.
>> >>
>> >> Duncan Murdoch
>
> I would have expected numeric(0) as the result (numeric(0) is the
> result from log(numeric(0)), etc).
>
> Martin (Morgan)
>
>
> Martin Maechler <[EMAIL PROTECTED]> writes:
>
>>> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
>>> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
>>
>> Ben> Duncan Murdoch wrote:
>> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
>> >>
>> >>> It surprised me that prod(numeric(0)) is 1. I guess if
>> >>> you say (operation(nothing) == identity element) this
>> >>> makes sense, but ??
>> >>
>> >>
>> >> What value were you expecting, or were you expecting an
>> >> error? I can't think how any other value could be
>> >> justified, and throwing an error would make a lot of
>> >> formulas more complicated.
>> >>
>> >>>
>> >>
>> consider exp(sum(log(numeric(0 ... ?)
>> >>
>> >> That's a fairly standard mathematical convention, which
>> >> is presumably why sum and prod work that way.
>> >>
>> >> Duncan Murdoch
>>
>> Ben>OK. I guess I was expecting NaN/NA (as opposed to
>> Ben> an error), but I take the "this makes everything else
>> Ben> more complicated" point. Should this be documented or
>> Ben> is it just too obvious ... ? (Funny -- I'm willing to
>> Ben> take gamma(1)==1 without any argument or suggestion
>> Ben> that it should be documented ...)
>>
>> see? so it looks to me as if you have finally convinced
>> yourself that '1' is the most reasonable result.. ;-)
>>
>> Anyway, I've added a sentence to help(prod) {which matches
>> the sentence in help(sum), BTW}.
>>
>> Martin
>>
>> __
>> 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] prod(numeric(0)) surprise
The way to think about it is:
prod(rep(x,n)) == x^n
and that works for n=0 too.
On 1/9/06, Martin Morgan <[EMAIL PROTECTED]> wrote:
> I'm a little confused. I understand that numeric(0) means an empty
> numeric vector, not the number 0 expressed as numeric. As it is now,
> prod(numeric(0)) generates something -- a vector of length 1
> containing the number 1 -- from nothing. I would have expected
>
> prod(numeric(0)) ==> numeric(0)
>
> this is consistent with
>
> numeric(0) ==> numeric(0)
> numeric(0) * 1 ==> numeric(0)
> cumprod(numeric(0)) ==> numeric(0)
>
> and, because concatenation occus before function evaluation,
>
> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
>
> I would expect sum() to behave the same way, e.g., sum(numeric(0)) ==>
> numeric(0). From below,
>
> > consider exp(sum(log(numeric(0 ... ?)
> > >>
> > >> That's a fairly standard mathematical convention, which
> > >> is presumably why sum and prod work that way.
> > >>
> > >> Duncan Murdoch
>
> I would have expected numeric(0) as the result (numeric(0) is the
> result from log(numeric(0)), etc).
>
> Martin (Morgan)
>
>
> Martin Maechler <[EMAIL PROTECTED]> writes:
>
> >> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
> >> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
> >
> > Ben> Duncan Murdoch wrote:
> > >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
> > >>
> > >>> It surprised me that prod(numeric(0)) is 1. I guess if
> > >>> you say (operation(nothing) == identity element) this
> > >>> makes sense, but ??
> > >>
> > >>
> > >> What value were you expecting, or were you expecting an
> > >> error? I can't think how any other value could be
> > >> justified, and throwing an error would make a lot of
> > >> formulas more complicated.
> > >>
> > >>>
> > >>
> > consider exp(sum(log(numeric(0 ... ?)
> > >>
> > >> That's a fairly standard mathematical convention, which
> > >> is presumably why sum and prod work that way.
> > >>
> > >> Duncan Murdoch
> >
> > Ben>OK. I guess I was expecting NaN/NA (as opposed to
> > Ben> an error), but I take the "this makes everything else
> > Ben> more complicated" point. Should this be documented or
> > Ben> is it just too obvious ... ? (Funny -- I'm willing to
> > Ben> take gamma(1)==1 without any argument or suggestion
> > Ben> that it should be documented ...)
> >
> > see? so it looks to me as if you have finally convinced
> > yourself that '1' is the most reasonable result.. ;-)
> >
> > Anyway, I've added a sentence to help(prod) {which matches
> > the sentence in help(sum), BTW}.
> >
> > Martin
> >
> > __
> > 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] prod(numeric(0)) surprise
I guess I have to say yes, I'd exepct
x <- 1:10
sum(x[x>10]) ==> numeric(0)
this would be reinforced by recongnizing that numeric(0) is not zero,
but nothing. I guess the summation over an empty set is an empty set,
rather than a set containing the number 0. Certainly these
exp(x[x>10]) ==> numeric(0)
numeric(0) + 1 ==> numeric(0)
would give me pause.
Gabor Grothendieck <[EMAIL PROTECTED]> writes:
> The way to think about it is:
>
>prod(rep(x,n)) == x^n
>
> and that works for n=0 too.
Hmm, Not sure what to put in for x and n? do you mean x == numeric(0),
n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty
set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these,
x^n evaluates to numeric(0).
Martin (Morgan)
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> On 1/9/2006 12:40 PM, Martin Morgan wrote:
>> I'm a little confused. I understand that numeric(0) means an empty
>> numeric vector, not the number 0 expressed as numeric. As it is now,
>> prod(numeric(0)) generates something -- a vector of length 1
>> containing the number 1 -- from nothing. I would have expected
>> prod(numeric(0)) ==> numeric(0)
>> this is consistent with
>> numeric(0) ==> numeric(0)
>> numeric(0) * 1 ==> numeric(0)
>> cumprod(numeric(0)) ==> numeric(0)
>> and, because concatenation occus before function evaluation,
>> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
>> I would expect sum() to behave the same way, e.g., sum(numeric(0))
>> ==>
>> numeric(0). From below,
>>
>
> I think the code below works as I'd expect. Would you really like the
> last answer to be numeric(0)?
>
> > x <- 1:10
> > sum(x)
> [1] 55
> > sum(x[x>5])
> [1] 40
> > sum(x[x>10])
> [1] 0
>
> Duncan Murdoch
>
>>> consider exp(sum(log(numeric(0 ... ?)
>>> >> >> That's a fairly standard mathematical convention,
>>> which
>>> >> is presumably why sum and prod work that way.
>>> >> >> Duncan Murdoch
>> I would have expected numeric(0) as the result (numeric(0) is the
>> result from log(numeric(0)), etc).
>> Martin (Morgan)
>> Martin Maechler <[EMAIL PROTECTED]> writes:
>>
"Ben" == Ben Bolker <[EMAIL PROTECTED]>
on Sun, 08 Jan 2006 21:40:05 -0500 writes:
>>>
>>> Ben> Duncan Murdoch wrote:
>>> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
>>> >> >>> It surprised me that prod(numeric(0)) is 1. I guess
>>> if
>>> >>> you say (operation(nothing) == identity element) this
>>> >>> makes sense, but ??
>>> >> >> >> What value were you expecting, or were you
>>> expecting an
>>> >> error? I can't think how any other value could be
>>> >> justified, and throwing an error would make a lot of
>>> >> formulas more complicated.
>>> >> >>>
>>> >> consider exp(sum(log(numeric(0 ... ?)
>>> >> >> That's a fairly standard mathematical convention,
>>> which
>>> >> is presumably why sum and prod work that way.
>>> >> >> Duncan Murdoch
>>>
>>> Ben>OK. I guess I was expecting NaN/NA (as opposed to
>>> Ben> an error), but I take the "this makes everything else
>>> Ben> more complicated" point. Should this be documented or
>>> Ben> is it just too obvious ... ? (Funny -- I'm willing to
>>> Ben> take gamma(1)==1 without any argument or suggestion
>>> Ben> that it should be documented ...)
>>>
>>> see? so it looks to me as if you have finally convinced
>>> yourself that '1' is the most reasonable result.. ;-)
>>>
>>> Anyway, I've added a sentence to help(prod) {which matches
>>> the sentence in help(sum), BTW}.
>>>
>>> Martin
>>>
>>> __
>>> 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] prod(numeric(0)) surprise
If you haven't seen this in your math courses, perhaps this would help:
http://en.wikipedia.org/wiki/Empty_set
which says, in part:
Operations on the empty set
Operations performed on the empty set (as a set of things to be operated
upon) can also be confusing. (Such operations are nullary operations.) For
example, the sum of the elements of the empty set is zero, but the product
of the elements of the empty set is one (see empty product). This may seem
odd, since there are no elements of the empty set, so how could it matter
whether they are added or multiplied (since "they" do not exist)?
Ultimately, the results of these operations say more about the operation in
question than about the empty set. For instance, notice that zero is the
identity element for addition, and one is the identity element for
multiplication.
Andy
From: Martin Morgan
>
> I guess I have to say yes, I'd exepct
>
> x <- 1:10
> sum(x[x>10]) ==> numeric(0)
>
> this would be reinforced by recongnizing that numeric(0) is not zero,
> but nothing. I guess the summation over an empty set is an empty set,
> rather than a set containing the number 0. Certainly these
>
> exp(x[x>10]) ==> numeric(0)
> numeric(0) + 1 ==> numeric(0)
>
> would give me pause.
>
>
> Gabor Grothendieck <[EMAIL PROTECTED]> writes:
>
> > The way to think about it is:
> >
> >prod(rep(x,n)) == x^n
> >
> > and that works for n=0 too.
>
> Hmm, Not sure what to put in for x and n? do you mean x == numeric(0),
> n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty
> set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these,
> x^n evaluates to numeric(0).
>
> Martin (Morgan)
>
> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
> > On 1/9/2006 12:40 PM, Martin Morgan wrote:
> >> I'm a little confused. I understand that numeric(0) means an empty
> >> numeric vector, not the number 0 expressed as numeric. As
> it is now,
> >> prod(numeric(0)) generates something -- a vector of length 1
> >> containing the number 1 -- from nothing. I would have expected
> >> prod(numeric(0)) ==> numeric(0)
> >> this is consistent with
> >> numeric(0) ==> numeric(0)
> >> numeric(0) * 1 ==> numeric(0)
> >> cumprod(numeric(0)) ==> numeric(0)
> >> and, because concatenation occus before function evaluation,
> >> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
> >> I would expect sum() to behave the same way, e.g., sum(numeric(0))
> >> ==>
> >> numeric(0). From below,
> >>
> >
> > I think the code below works as I'd expect. Would you
> really like the
> > last answer to be numeric(0)?
> >
> > > x <- 1:10
> > > sum(x)
> > [1] 55
> > > sum(x[x>5])
> > [1] 40
> > > sum(x[x>10])
> > [1] 0
> >
> > Duncan Murdoch
> >
> >>> consider exp(sum(log(numeric(0 ... ?)
> >>> >> >> That's a fairly standard mathematical convention,
> >>> which
> >>> >> is presumably why sum and prod work that way.
> >>> >> >> Duncan Murdoch
> >> I would have expected numeric(0) as the result (numeric(0) is the
> >> result from log(numeric(0)), etc).
> >> Martin (Morgan)
> >> Martin Maechler <[EMAIL PROTECTED]> writes:
> >>
> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
> >>>
> >>> Ben> Duncan Murdoch wrote:
> >>> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
> >>> >> >>> It surprised me that prod(numeric(0)) is
> 1. I guess
> >>> if
> >>> >>> you say (operation(nothing) == identity element) this
> >>> >>> makes sense, but ??
> >>> >> >> >> What value were you expecting, or were you
> >>> expecting an
> >>> >> error? I can't think how any other value could be
> >>> >> justified, and throwing an error would make a lot of
> >>> >> formulas more complicated.
> >>> >> >>>
> >>> >> consider exp(sum(log(numeric(0 ... ?)
> >>> >> >> That's a fairly standard mathematical convention,
> >>> which
> >>> >> is presumably why sum and prod work that way.
> >>> >> >> Duncan Murdoch
> >>>
> >>> Ben>OK. I guess I was expecting NaN/NA (as opposed to
> >>> Ben> an error), but I take the "this makes everything else
> >>> Ben> more complicated" point. Should this be documented or
> >>> Ben> is it just too obvious ... ? (Funny -- I'm willing to
> >>> Ben> take gamma(1)==1 without any argument or suggestion
> >>> Ben> that it should be documented ...)
> >>>
> >>> see? so it looks to me as if you have finally convinced
> >>> yourself that '1' is the most reasonable result.. ;-)
> >>>
> >>> Anyway, I've added a sentence to help(prod) {which matches
> >>> the sentence in help(sum), BTW}.
> >>>
> >>> Martin
> >>>
> >>> __
> >>> 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] prod(numeric(0)) surprise
On 1/9/2006 1:27 PM, Liaw, Andy wrote:
> If you haven't seen this in your math courses, perhaps this would help:
>
> http://en.wikipedia.org/wiki/Empty_set
>
This is what is so great about Wikipedia: it gives certainty where I'd
only call it a fairly standard convention. ;-)
Duncan Murdoch
> which says, in part:
>
> Operations on the empty set
>
> Operations performed on the empty set (as a set of things to be operated
> upon) can also be confusing. (Such operations are nullary operations.) For
> example, the sum of the elements of the empty set is zero, but the product
> of the elements of the empty set is one (see empty product). This may seem
> odd, since there are no elements of the empty set, so how could it matter
> whether they are added or multiplied (since "they" do not exist)?
> Ultimately, the results of these operations say more about the operation in
> question than about the empty set. For instance, notice that zero is the
> identity element for addition, and one is the identity element for
> multiplication.
>
>
> Andy
>
>
> From: Martin Morgan
>>
>> I guess I have to say yes, I'd exepct
>>
>> x <- 1:10
>> sum(x[x>10]) ==> numeric(0)
>>
>> this would be reinforced by recongnizing that numeric(0) is not zero,
>> but nothing. I guess the summation over an empty set is an empty set,
>> rather than a set containing the number 0. Certainly these
>>
>> exp(x[x>10]) ==> numeric(0)
>> numeric(0) + 1 ==> numeric(0)
>>
>> would give me pause.
>>
>>
>> Gabor Grothendieck <[EMAIL PROTECTED]> writes:
>>
>> > The way to think about it is:
>> >
>> >prod(rep(x,n)) == x^n
>> >
>> > and that works for n=0 too.
>>
>> Hmm, Not sure what to put in for x and n? do you mean x == numeric(0),
>> n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty
>> set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these,
>> x^n evaluates to numeric(0).
>>
>> Martin (Morgan)
>>
>> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>
>> > On 1/9/2006 12:40 PM, Martin Morgan wrote:
>> >> I'm a little confused. I understand that numeric(0) means an empty
>> >> numeric vector, not the number 0 expressed as numeric. As
>> it is now,
>> >> prod(numeric(0)) generates something -- a vector of length 1
>> >> containing the number 1 -- from nothing. I would have expected
>> >> prod(numeric(0)) ==> numeric(0)
>> >> this is consistent with
>> >> numeric(0) ==> numeric(0)
>> >> numeric(0) * 1 ==> numeric(0)
>> >> cumprod(numeric(0)) ==> numeric(0)
>> >> and, because concatenation occus before function evaluation,
>> >> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
>> >> I would expect sum() to behave the same way, e.g., sum(numeric(0))
>> >> ==>
>> >> numeric(0). From below,
>> >>
>> >
>> > I think the code below works as I'd expect. Would you
>> really like the
>> > last answer to be numeric(0)?
>> >
>> > > x <- 1:10
>> > > sum(x)
>> > [1] 55
>> > > sum(x[x>5])
>> > [1] 40
>> > > sum(x[x>10])
>> > [1] 0
>> >
>> > Duncan Murdoch
>> >
>> >>> consider exp(sum(log(numeric(0 ... ?)
>> >>> >> >> That's a fairly standard mathematical convention,
>> >>> which
>> >>> >> is presumably why sum and prod work that way.
>> >>> >> >> Duncan Murdoch
>> >> I would have expected numeric(0) as the result (numeric(0) is the
>> >> result from log(numeric(0)), etc).
>> >> Martin (Morgan)
>> >> Martin Maechler <[EMAIL PROTECTED]> writes:
>> >>
>> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
>> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
>> >>>
>> >>> Ben> Duncan Murdoch wrote:
>> >>> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
>> >>> >> >>> It surprised me that prod(numeric(0)) is
>> 1. I guess
>> >>> if
>> >>> >>> you say (operation(nothing) == identity element) this
>> >>> >>> makes sense, but ??
>> >>> >> >> >> What value were you expecting, or were you
>> >>> expecting an
>> >>> >> error? I can't think how any other value could be
>> >>> >> justified, and throwing an error would make a lot of
>> >>> >> formulas more complicated.
>> >>> >> >>>
>> >>> >> consider exp(sum(log(numeric(0 ... ?)
>> >>> >> >> That's a fairly standard mathematical convention,
>> >>> which
>> >>> >> is presumably why sum and prod work that way.
>> >>> >> >> Duncan Murdoch
>> >>>
>> >>> Ben>OK. I guess I was expecting NaN/NA (as opposed to
>> >>> Ben> an error), but I take the "this makes everything else
>> >>> Ben> more complicated" point. Should this be documented or
>> >>> Ben> is it just too obvious ... ? (Funny -- I'm willing to
>> >>> Ben> take gamma(1)==1 without any argument or suggestion
>> >>> Ben> that it should be documented ...)
>> >>>
>> >>> see? so it looks to me as if you have finally convinced
>> >>> yourself that '1' is the most reasonable result.. ;-)
>> >>>
>> >>> Anyway, I've added a sentence to help(prod) {which matches
>> >>> the sente
Re: [Rd] prod(numeric(0)) surprise
Duncan Murdoch <[EMAIL PROTECTED]> writes: > On 1/9/2006 1:27 PM, Liaw, Andy wrote: >> If you haven't seen this in your math courses, perhaps this would help: >> http://en.wikipedia.org/wiki/Empty_set >> > > This is what is so great about Wikipedia: it gives certainty where > I'd only call it a fairly standard convention. ;-) > > Duncan Murdoch Yes, thanks for the refresher and sorry for the noise. Martin >> which says, in part: >> Operations on the empty set >> Operations performed on the empty set (as a set of things to be >> operated >> upon) can also be confusing. (Such operations are nullary operations.) For >> example, the sum of the elements of the empty set is zero, but the product >> of the elements of the empty set is one (see empty product). This may seem >> odd, since there are no elements of the empty set, so how could it matter >> whether they are added or multiplied (since "they" do not exist)? >> Ultimately, the results of these operations say more about the operation in >> question than about the empty set. For instance, notice that zero is the >> identity element for addition, and one is the identity element for >> multiplication. >> Andy >> From: Martin Morgan >>> I guess I have to say yes, I'd exepct >>> x <- 1:10 >>> sum(x[x>10]) ==> numeric(0) >>> this would be reinforced by recongnizing that numeric(0) is not >>> zero, >>> but nothing. I guess the summation over an empty set is an empty set, >>> rather than a set containing the number 0. Certainly these >>> exp(x[x>10]) ==> numeric(0) >>> numeric(0) + 1 ==> numeric(0) >>> would give me pause. >>> Gabor Grothendieck <[EMAIL PROTECTED]> writes: >>> > The way to think about it is: >>> > >>> >prod(rep(x,n)) == x^n >>> > >>> > and that works for n=0 too. >>> Hmm, Not sure what to put in for x and n? do you mean x == >>> numeric(0), >>> n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty >>> set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these, >>> x^n evaluates to numeric(0). >>> Martin (Morgan) >>> Duncan Murdoch <[EMAIL PROTECTED]> writes: >>> > On 1/9/2006 12:40 PM, Martin Morgan wrote: >>> >> I'm a little confused. I understand that numeric(0) means an empty >>> >> numeric vector, not the number 0 expressed as numeric. As it is >>> now, >>> >> prod(numeric(0)) generates something -- a vector of length 1 >>> >> containing the number 1 -- from nothing. I would have expected >>> >> prod(numeric(0)) ==> numeric(0) >>> >> this is consistent with >>> >> numeric(0) ==> numeric(0) >>> >> numeric(0) * 1 ==> numeric(0) >>> >> cumprod(numeric(0)) ==> numeric(0) >>> >> and, because concatenation occus before function evaluation, >>> >> prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1 >>> >> I would expect sum() to behave the same way, e.g., sum(numeric(0)) >>> >> ==> >>> >> numeric(0). From below, >>> >> >>> > >>> > I think the code below works as I'd expect. Would you really >>> like the >>> > last answer to be numeric(0)? >>> > >>> > > x <- 1:10 >>> > > sum(x) >>> > [1] 55 >>> > > sum(x[x>5]) >>> > [1] 40 >>> > > sum(x[x>10]) >>> > [1] 0 >>> > >>> > Duncan Murdoch >>> > >>> >>> consider exp(sum(log(numeric(0 ... ?) >>> >>> >> >> That's a fairly standard mathematical convention, >>> >>> which >>> >>> >> is presumably why sum and prod work that way. >>> >>> >> >> Duncan Murdoch >>> >> I would have expected numeric(0) as the result (numeric(0) is the >>> >> result from log(numeric(0)), etc). >>> >> Martin (Morgan) >>> >> Martin Maechler <[EMAIL PROTECTED]> writes: >>> >> >>> "Ben" == Ben Bolker <[EMAIL PROTECTED]> >>> on Sun, 08 Jan 2006 21:40:05 -0500 writes: >>> >>> >>> >>> Ben> Duncan Murdoch wrote: >>> >>> >> On 1/8/2006 9:24 PM, Ben Bolker wrote: >>> >>> >> >>> It surprised me that prod(numeric(0)) is 1. I >>> guess >>> >>> if >>> >>> >>> you say (operation(nothing) == identity element) this >>> >>> >>> makes sense, but ?? >>> >>> >> >> >> What value were you expecting, or were you >>> >>> expecting an >>> >>> >> error? I can't think how any other value could be >>> >>> >> justified, and throwing an error would make a lot of >>> >>> >> formulas more complicated. >>> >>> >> >>> >>> >>> >> consider exp(sum(log(numeric(0 ... ?) >>> >>> >> >> That's a fairly standard mathematical convention, >>> >>> which >>> >>> >> is presumably why sum and prod work that way. >>> >>> >> >> Duncan Murdoch >>> >>> >>> >>> Ben>OK. I guess I was expecting NaN/NA (as opposed to >>> >>> Ben> an error), but I take the "this makes everything else >>> >>> Ben> more complicated" point. Should this be documented or >>> >>> Ben> is it just too obvious ... ? (Funny -- I'm willing to >>> >>> Ben> take gamma(1)==1 without any argument or suggestion >>> >>> Ben> that it should be documented ...) >>> >>> >>> >>> see? so it looks to me as if you have final
Re: [Rd] confint/nls
These are all solved, except those for "plinear", where you cannot profile
linear parameters and so you must specify parms (or call
confint(profile(fm)). And the third plinear model does not converge, so
isn't a useful test.
On Sat, 7 Jan 2006, Ben Bolker wrote:
>
> I have found some "issues" (bugs?) with nls confidence intervals ...
> some with the relatively new "port" algorithm, others more general
> (but possibly in the "well, don't do that" category). I have
> corresponded some with Prof. Ripley about them, but I thought I
> would just report how far I've gotten in case anyone else has
> thoughts. (I'm finding the code in stats/nls.R and stats/nle-profile.R
> quite dense & scary ...)
> All of this has been done with R-devel from 3 Jan 2006; the changes
> that Prof. Ripley already made to allow confint.nls not to crash
> when algorithm="port" are in R-devel, not R-patched.
>
> a synopsis of the problems with confint():
>
> with a 1-parameter model (is confint not appropriate for 1-parameter
> models? it doesn't say so in the docs [by the way, "normality" is
> misspelled as "nornality" in ?confint]):
>
>algorithm=default or plinear: get a complaint from qr.qty ('qr' and
> 'y' must have the same number of rows)
>port: "cannot allocate vector of size [large]" [caused by C code
> looking for dims when they aren't there]
>
> 2-parameter models:
>default OK
>port "cannot allocate vector"
>plinear"Error in xy.coords"
>
> 3-parameter models are OK
>
> I can fix the 2-parameter port case by adding drop=FALSE in
> appropriate places, but I wanted to check in just in case
> there are better/more efficient ways than my slogging through
> one case at a time ...
>
> apologies for the long message, but I am temporarily cut
> off from any way to post these files to the web.
>
> cheers
> Ben Bolker
>
> code that tests various combinations of numbers of parameters
> and algorithms:
> ---
> resmat = array(dim=c(3,2,3),
> dimnames=list(npar=1:3,c("fit","confint"),c("default","plinear","port")))
> resmat.fix <- resmat
> ## sim. values
> npts=1000
> set.seed(1001)
> x = runif(npts)
> b = 0.7
> y = x^b+rnorm(npts,sd=0.05)
> a =0.5
> y2 = a*x^b+rnorm(npts,sd=0.05)
> c = 1.0
> y3 = a*(x+c)^b+rnorm(npts,sd=0.05)
> d = 0.5
> y4 = a*(x^d+c)^b+rnorm(npts,sd=0.05)
>
> testfit <- function(model,start,alg) {
> tryfit <- try(fit <-
> nls(model,start=start,algorithm=alg,control=list(maxiter=200)))
> if (class(tryfit)!="try-error") {
> fitcode="OK"
> tryci <- try(confint(fit))
> if (class(tryci)!="try-error") {
> cicode="OK"
> } else cicode = as.character(tryci)
> } else {
> fitcode = as.character(tryfit)
> cicode="?"
> }
> c(fitcode,cicode)
> }
>
> m1 = c(y~x^b,y2~a*x^b,y3~a*(x+exp(logc))^b)
> m2 = c(y2~x^b,y3~(x+exp(logc))^b,y4~(x^d+exp(logc))^b)
> s1 = list(c(b=1),c(a=1,b=1),c(a=1,b=1,logc=0))
> s2 = list(c(b=1),c(b=1,logc=0),c(b=1,logc=0,d=0.5))
>
> for (p in 1:3) {
> resmat[p,,"default"] <- testfit(m1[[p]],start=s1[[p]],alg=NULL)
> resmat[p,,"port"] <- testfit(m1[[p]],start=s1[[p]],alg="port")
> }
>
> for (p in 1:3) {
> resmat[p,,"plinear"] <- testfit(m2[[p]],start=s2[[p]],alg="plinear")
> }
>
> print(resmat)
> set.seed(1002)
> example(nls,local=TRUE)
>
> diffs:
> --
> *** /usr/local/src/R/R-devel/src/library/stats/R/nls.R 2006-01-07
> 10:57:08.0 -0500
> --- nlsnew.R2006-01-07 19:18:53.0 -0500
> ***
> *** 266,277
> gradSetArgs[[1]] <- (~attr(ans, "gradient"))[[2]]
> gradCall <-
> switch(length(gradSetArgs) - 1,
> !call("[", gradSetArgs[[1]], gradSetArgs[[2]]),
> !call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]]),
> call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]],
> ! gradSetArgs[[3]]),
> call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]],
> ! gradSetArgs[[3]], gradSetArgs[[4]]))
> getRHS.varying <- function()
> {
> ans <- getRHS.noVarying()
> --- 266,277
> gradSetArgs[[1]] <- (~attr(ans, "gradient"))[[2]]
> gradCall <-
> switch(length(gradSetArgs) - 1,
> !call("[", gradSetArgs[[1]], gradSetArgs[[2]],drop=FALSE),
> !call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]],drop=FALSE),
> call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]],
> ! gradSetArgs[[3]],drop=FALSE),
> call("[", gradSetArgs[[1]], gradSetArgs[[2]],
> gradSetArgs[[2]],
> ! gradSetArgs[[3]], gradSetArgs[[4]],drop=FALSE))
> getRHS.varying <- function()
> {
> ans <- getRHS.noVarying()
> ***
> *** 331,337
> else {
> vary
> }, envir = thisEnv)
> ! gradCall[[length(
Re: [Rd] prod(numeric(0)) surprise
On Mon, 9 Jan 2006, Martin Morgan wrote: > I guess I have to say yes, I'd exepct > > x <- 1:10 > sum(x[x>10]) ==> numeric(0) > > this would be reinforced by recongnizing that numeric(0) is not zero, > but nothing. I guess the summation over an empty set is an empty set, > rather than a set containing the number 0. Certainly these > > exp(x[x>10]) ==> numeric(0) > numeric(0) + 1 ==> numeric(0) > There are some fairly simple rules in how R does it. You do need to distinguish between functions (binary operators) that map two vectors of length n to a vector of length n and functions such as prod and sum that map a vector of length n to a vector of length 1. The output of sum and prod is always of length 1, so sum(numeric(0)) and prod(numeric(0)) should be of length 1 (or give an error). It is convenient that sum(c(x,y)) is equal to sum(x)+sum(y) and that prod(c(x,y)) is equal to prod(x)*prod(y), which motivates making sum(numeric(0)) give 0 and prod(numeric(0)) give 1. Single argument functions such as exp(numeric(0)) seem fairly obvious: you have no numbers and you exponentiate them so you still have no numbers. You could also argue based on c() and exp() commuting. The rules for binary operators are a little less tidy [my fault]. They come from the idea that x+1 should always add 1 to each element of x. If you add 1 to each element of numeric(0) you get numeric(0). The usual recycling rule says that the shorter vector should be repeated to make it the same length as the longer vector, so this is a wart. On the other hand, you can't recycle a vector of length 0 to have length 1, so the usual recycling rule can't be applied here. This also makes matrix operations work, at least in the sense of getting matrices of the right dimension. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Interfacing R and C++
I have a single c++ file that contains a class and a "wrapper" function that
has C-like syntax for interacting with the Class. Basically, this wrapper
function just makes an instance of the class and then organizes the data for
return to R.
#include
void myFunc(double *data, int *n, double *prm, double* intervals, int* max,
double *plot) {
...
}
myClass::myclass(...) {
...
}
My question is simple: what goes inside the extern "C" {} block. Should it
include only the #includes, those and the "wrapper" function, or the entire
.cc file? The answer wasn't clear to me from the Writing R extensions
manual (probably due to my c++ ignorance--using someone else's code).
> sessionInfo()
R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
I'm trying to use the .C interface and getting segmentation faults--probably
a bug in the code, but just wanted to make sure that it wasn't a simple
issue with the extern block.
Thanks,
Sean
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interfacing R and C++
The wrapper function must be in extern "C" {} since you want to give it a
C name (and not a mangled C++ one). These days, the headers probably do
not need to be, but in theory if they are C headers they should be in any
C++ code.
I think R-exts is quite clear on this:
To use with @R{}, the only thing we have to do is writing a wrapper
function and ensuring that the function is enclosed in
On Mon, 9 Jan 2006, Sean Davis wrote:
> I have a single c++ file that contains a class and a "wrapper" function that
> has C-like syntax for interacting with the Class. Basically, this wrapper
> function just makes an instance of the class and then organizes the data for
> return to R.
>
> #include
>
> void myFunc(double *data, int *n, double *prm, double* intervals, int* max,
> double *plot) {
> ...
> }
>
> myClass::myclass(...) {
> ...
> }
>
> My question is simple: what goes inside the extern "C" {} block. Should it
> include only the #includes, those and the "wrapper" function, or the entire
> .cc file? The answer wasn't clear to me from the Writing R extensions
> manual (probably due to my c++ ignorance--using someone else's code).
>
>> sessionInfo()
> R version 2.2.0, 2005-08-11, powerpc-apple-darwin7.9.0
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> I'm trying to use the .C interface and getting segmentation faults--probably
> a bug in the code, but just wanted to make sure that it wasn't a simple
> issue with the extern block.
>
> Thanks,
> Sean
>
> __
> 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] prod(numeric(0)) surprise
On Mon, 9 Jan 2006, Thomas Lumley wrote: > On Mon, 9 Jan 2006, Martin Morgan wrote: > >> I guess I have to say yes, I'd exepct >> >> x <- 1:10 >> sum(x[x>10]) ==> numeric(0) >> >> this would be reinforced by recongnizing that numeric(0) is not zero, >> but nothing. I guess the summation over an empty set is an empty set, >> rather than a set containing the number 0. Certainly these >> >> exp(x[x>10]) ==> numeric(0) >> numeric(0) + 1 ==> numeric(0) >> > > There are some fairly simple rules in how R does it. You do need to > distinguish between functions (binary operators) that map two vectors of > length n to a vector of length n and functions such as prod and sum that > map a vector of length n to a vector of length 1. > > The output of sum and prod is always of length 1, so sum(numeric(0)) and > prod(numeric(0)) should be of length 1 (or give an error). It is > convenient that sum(c(x,y)) is equal to sum(x)+sum(y) and that > prod(c(x,y)) is equal to prod(x)*prod(y), which motivates making > sum(numeric(0)) give 0 and prod(numeric(0)) give 1. > > Single argument functions such as exp(numeric(0)) seem fairly obvious: you > have no numbers and you exponentiate them so you still have no numbers. > You could also argue based on c() and exp() commuting. > > The rules for binary operators are a little less tidy [my fault]. They > come from the idea that x+1 should always add 1 to each element of x. If > you add 1 to each element of numeric(0) you get numeric(0). The usual > recycling rule says that the shorter vector should be repeated to make it > the same length as the longer vector, so this is a wart. On the other > hand, you can't recycle a vector of length 0 to have length 1, so the > usual recycling rule can't be applied here. This also makes matrix > operations work, at least in the sense of getting > matrices of the right dimension. There is an Svr4 addendum to the original S recycling rule which R implements: any vector/array expression with a length-0 component has a length-0 result. (Note the qualifier in there.) See `S Programming' pp. 17,27 for more details. So the `wart' is part of a general rule. -- 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] Interfacing R and C++
On 1/9/06 3:20 PM, "Prof Brian Ripley" <[EMAIL PROTECTED]> wrote:
> The wrapper function must be in extern "C" {} since you want to give it a
> C name (and not a mangled C++ one). These days, the headers probably do
> not need to be, but in theory if they are C headers they should be in any
> C++ code.
>
> I think R-exts is quite clear on this:
>
>To use with @R{}, the only thing we have to do is writing a wrapper
>function and ensuring that the function is enclosed in
>
Yes, the documentation is clear, provided one knows what name-mangling is
and why it is important, which I now understand better.
Thanks,
Sean
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] ouml in an .Rd
(moved from r-help)
Ok, UTF-8 works on some of my machines and latin1 on others. If I use
one I get failure or spurious characters when I build on the wrong
machine. Are .Rd files suppose to work on different platforms when there
are special characters, or is this a known limitation?
Paul
Prof Brian Ripley wrote:
> It means what it says: you need to put the actual character in the file,
> and specify the encoding for the file via \encoding. (For you, UTF-8 or
> latin1, I would guess.)
>
> It's not a question of trying variations, rather of following instructions.
>
> On Fri, 6 Jan 2006, Paul Gilbert wrote:
>
>> I am trying to put an ouml in an .Rd file with no success. Writing R
>> Extensions suggests:
>>
>> Text which might need to be represented differently in different
>> encodings should be marked by |\enc|, e.g. |\enc{Jöreskog}{Joreskog}|
>> where the first argument will be used where encodings are allowed and
>> the second should be ASCII (and is used for e.g. the text conversion).
>>
>> (Above may get mangled by the mail.) I have tried variations
>>
>> \enc{J"oreskog}{Joreskog}
>> \enc{J\"oreskog}{Joreskog}
>> \enc{Jo\"reskog}{Joreskog}
>> \enc{Jo\"reskog}{Joreskog}
>> \enc{J\"{o}reskog}{Joreskog}
>> \enc{J\\"{o}reskog}{Joreskog}
>> \enc{Jöoreskog}{Joreskog}
>>
>> all with no effect on the generated pdf file. Suggestions would be
>> appreciated.
>>
>> Thanks,
>> Paul Gilbert
>>
>> __
>> R-help@stat.math.ethz.ch mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide!
>> http://www.R-project.org/posting-guide.html
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(numeric(0)) surprise
But this thread seems to have pointed to some inconsistencies:
> cumprod( numeric(0) )
numeric(0)
> cumsum( numeric(0) )
numeric(0)
shouldn't this give the same as prod() and sum()
in this case?
Same with cummin() and cummax().
Kjetil
On 1/9/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>
> On 1/9/2006 12:40 PM, Martin Morgan wrote:
> > I'm a little confused. I understand that numeric(0) means an empty
> > numeric vector, not the number 0 expressed as numeric. As it is now,
> > prod(numeric(0)) generates something -- a vector of length 1
> > containing the number 1 -- from nothing. I would have expected
> >
> > prod(numeric(0)) ==> numeric(0)
> >
> > this is consistent with
> >
> > numeric(0) ==> numeric(0)
> > numeric(0) * 1 ==> numeric(0)
> > cumprod(numeric(0)) ==> numeric(0)
> >
> > and, because concatenation occus before function evaluation,
> >
> > prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
> >
> > I would expect sum() to behave the same way, e.g., sum(numeric(0)) ==>
> > numeric(0). From below,
> >
>
> I think the code below works as I'd expect. Would you really like the
> last answer to be numeric(0)?
>
> > x <- 1:10
> > sum(x)
> [1] 55
> > sum(x[x>5])
> [1] 40
> > sum(x[x>10])
> [1] 0
>
> Duncan Murdoch
>
> >> consider exp(sum(log(numeric(0 ... ?)
> >> >>
> >> >> That's a fairly standard mathematical convention, which
> >> >> is presumably why sum and prod work that way.
> >> >>
> >> >> Duncan Murdoch
> >
> > I would have expected numeric(0) as the result (numeric(0) is the
> > result from log(numeric(0)), etc).
> >
> > Martin (Morgan)
> >
> >
> > Martin Maechler <[EMAIL PROTECTED]> writes:
> >
> >>> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
> >>> on Sun, 08 Jan 2006 21:40:05 -0500 writes:
> >>
> >> Ben> Duncan Murdoch wrote:
> >> >> On 1/8/2006 9:24 PM, Ben Bolker wrote:
> >> >>
> >> >>> It surprised me that prod(numeric(0)) is 1. I guess if
> >> >>> you say (operation(nothing) == identity element) this
> >> >>> makes sense, but ??
> >> >>
> >> >>
> >> >> What value were you expecting, or were you expecting an
> >> >> error? I can't think how any other value could be
> >> >> justified, and throwing an error would make a lot of
> >> >> formulas more complicated.
> >> >>
> >> >>>
> >> >>
> >> consider exp(sum(log(numeric(0 ... ?)
> >> >>
> >> >> That's a fairly standard mathematical convention, which
> >> >> is presumably why sum and prod work that way.
> >> >>
> >> >> Duncan Murdoch
> >>
> >> Ben>OK. I guess I was expecting NaN/NA (as opposed to
> >> Ben> an error), but I take the "this makes everything else
> >> Ben> more complicated" point. Should this be documented or
> >> Ben> is it just too obvious ... ? (Funny -- I'm willing to
> >> Ben> take gamma(1)==1 without any argument or suggestion
> >> Ben> that it should be documented ...)
> >>
> >> see? so it looks to me as if you have finally convinced
> >> yourself that '1' is the most reasonable result.. ;-)
> >>
> >> Anyway, I've added a sentence to help(prod) {which matches
> >> the sentence in help(sum), BTW}.
> >>
> >> Martin
> >>
> >> __
> >> 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
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(numeric(0)) surprise
On Jan 9, 2006, at 3:35 PM, Kjetil Halvorsen wrote: > But this thread seems to have pointed to some inconsistencies: > >> cumprod( numeric(0) ) > numeric(0) >> cumsum( numeric(0) ) > numeric(0) > > shouldn't this give the same as prod() and sum() in this case? No - as Thomas explained very nicely they are a different kind of functions. cumXXX are n-to-n length vector functions, whereas prod/ sum are n to 1 vector length functions. So R is in fact very consistent and Thomas did exactly describe the rules. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] prod(numeric(0)) surprise
Since the virtue and reliability of Wikis was brought up, I created a R Wiki page for this at http://www.sciviews.org/_rgui/wiki/doku.php?id=beginners:surprises:emptysetfuncs :-) Anyone: please correct errors and improve it! Tony Plate Duncan Murdoch wrote: > On 1/9/2006 1:27 PM, Liaw, Andy wrote: > >>If you haven't seen this in your math courses, perhaps this would help: >> >>http://en.wikipedia.org/wiki/Empty_set >> > > > This is what is so great about Wikipedia: it gives certainty where I'd > only call it a fairly standard convention. ;-) > > Duncan Murdoch > > > >>which says, in part: >> >>Operations on the empty set >> >>Operations performed on the empty set (as a set of things to be operated >>upon) can also be confusing. (Such operations are nullary operations.) For >>example, the sum of the elements of the empty set is zero, but the product >>of the elements of the empty set is one (see empty product). This may seem >>odd, since there are no elements of the empty set, so how could it matter >>whether they are added or multiplied (since "they" do not exist)? >>Ultimately, the results of these operations say more about the operation in >>question than about the empty set. For instance, notice that zero is the >>identity element for addition, and one is the identity element for >>multiplication. >> >> >>Andy >> >> >>From: Martin Morgan >> >>>I guess I have to say yes, I'd exepct >>> >>>x <- 1:10 >>>sum(x[x>10]) ==> numeric(0) >>> >>>this would be reinforced by recongnizing that numeric(0) is not zero, >>>but nothing. I guess the summation over an empty set is an empty set, >>>rather than a set containing the number 0. Certainly these >>> >>>exp(x[x>10]) ==> numeric(0) >>>numeric(0) + 1 ==> numeric(0) >>> >>>would give me pause. >>> >>> >>>Gabor Grothendieck <[EMAIL PROTECTED]> writes: >>> >>> The way to think about it is: prod(rep(x,n)) == x^n and that works for n=0 too. >>> >>>Hmm, Not sure what to put in for x and n? do you mean x == numeric(0), >>>n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty >>>set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these, >>>x^n evaluates to numeric(0). >>> >>>Martin (Morgan) >>> >>>Duncan Murdoch <[EMAIL PROTECTED]> writes: >>> >>> On 1/9/2006 12:40 PM, Martin Morgan wrote: >I'm a little confused. I understand that numeric(0) means an empty >numeric vector, not the number 0 expressed as numeric. As >>> >>>it is now, >>> >prod(numeric(0)) generates something -- a vector of length 1 >containing the number 1 -- from nothing. I would have expected >prod(numeric(0)) ==> numeric(0) >this is consistent with >numeric(0) ==> numeric(0) >numeric(0) * 1 ==> numeric(0) >cumprod(numeric(0)) ==> numeric(0) >and, because concatenation occus before function evaluation, >prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1 >I would expect sum() to behave the same way, e.g., sum(numeric(0)) >==> >numeric(0). From below, > I think the code below works as I'd expect. Would you >>> >>>really like the >>> last answer to be numeric(0)? > x <- 1:10 > sum(x) [1] 55 > sum(x[x>5]) [1] 40 > sum(x[x>10]) [1] 0 Duncan Murdoch >> consider exp(sum(log(numeric(0 ... ?) >>>> >> That's a fairly standard mathematical convention, >>which >>>> is presumably why sum and prod work that way. >>>> >> Duncan Murdoch > >I would have expected numeric(0) as the result (numeric(0) is the >result from log(numeric(0)), etc). >Martin (Morgan) >Martin Maechler <[EMAIL PROTECTED]> writes: > > >>>"Ben" == Ben Bolker <[EMAIL PROTECTED]> >>>on Sun, 08 Jan 2006 21:40:05 -0500 writes: >> >>Ben> Duncan Murdoch wrote: >>>> On 1/8/2006 9:24 PM, Ben Bolker wrote: >>>> >>> It surprised me that prod(numeric(0)) is >>> >>>1. I guess >>> >>if >>>>> you say (operation(nothing) == identity element) this >>>>> makes sense, but ?? >>>> >> >> What value were you expecting, or were you >>expecting an >>>> error? I can't think how any other value could be >>>> justified, and throwing an error would make a lot of >>>> formulas more complicated. >>>> >>> >>>> consider exp(sum(log(numeric(0 ... ?) >>>> >> That's a fairly standard mathematical convention, >>which >>>> is presumably why sum and prod work that way. >>>> >> Duncan Murdoch >> >>Ben>OK. I guess I was expecting NaN/NA (as opposed to >>Ben> an error), but I take the "this makes everything else >>Ben> more complicated" point. Should this be documented or >>Ben> is it just too obvious ... ? (Funny -- I'm willing to >>Ben> take gamma(1)==1 without any argument or su
[Rd] Wikis (was about prod(numeric(0)))
Tony Plate acm.org> writes: > > Since the virtue and reliability of Wikis was brought up, I created a R > Wiki page for this at > http://www.sciviews.org/_rgui/wiki/doku.php?id=beginners:surprises:emptysetfuncs > > > Anyone: please correct errors and improve it! > > Tony Plate > OK, now I have another question: I see a wiki at http://fawn.unibw-hamburg.de/cgi-bin/Rwiki.pl?RwikiHome administered by Detlef Steuer I see another at http://www.sciviews.org/_rgui/wiki/doku.php (Phillippe Grosjean) which is nominally geared toward beginners/GUI interfaces. I'm not saying I could do any better, but both of these look as though they'd be pretty hard to get into if you were really a beginner or intermediate R user looking for info ... Paul John's Rtips (http://www.ku.edu/~pauljohn/R/Rtips.html) is actually about the best example about there -- the flat hierarchy might not work too well for a really big wiki, but having at least a good first-level hierarchy set up (and making sure that what new users see is not a lot of detail about how to extend the wiki) seems really important. Sorry to criticize, but I am happy to start working on populating a wiki -- but only if the structure is there so that I can figure out where to put stuff and hope that someone who needs it will ever be able to find it ... -- 620B Bartram Hall[EMAIL PROTECTED] Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker Box 118525 (ph) 352-392-5697 Gainesville, FL 32611-8525 (fax) 352-392-3704 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wikis (was about prod(numeric(0)))
I agree with everything you say about the structure and organization of the Wiki (needs top-level R-related structure, the Wiki-administration/editing stuff dominates, etc.) But, it's also possible to spend so much time talking about how to do it, that it never gets done... Still, it really does look like it would be worth putting some effort into the top level structure early on, because from the material I saw about maintaining the wiki, it looks like a bit of a chore to impose a new top-level structure (requires scripts, admittedly simple, that rename files and change links within files -- so, presumably, can only be done by the Wiki administrator.) Also, I had a little difficulty figuring out exactly how to create new pages, and my attempts were not clean -- I seemed to have left two items with the same name at the same level in the index. Everything is an experiment! Maybe when Phillippe Grosjean returns to his work he can put some more R-related top-level structure on his wiki? In the meantime, anyone else can go in there and start proposing some structure... -- Tony Plate PS. Detlef Steuer did say that he would be happy to shut down his wiki and let the sciviews one be "the" R Wiki. I had previously put some material on Detlef's Wiki, but this time on put it on the sciviews Wiki. Ben Bolker wrote: > Tony Plate acm.org> writes: > > > > > Since the virtue and reliability of Wikis was brought up, I created a R > > Wiki page for this at > > > http://www.sciviews.org/_rgui/wiki/doku.php?id=beginners:surprises:emptysetfuncs > > > > > > Anyone: please correct errors and improve it! > > > > Tony Plate > > > >OK, now I have another question: > I see a wiki at > http://fawn.unibw-hamburg.de/cgi-bin/Rwiki.pl?RwikiHome > administered by Detlef Steuer >I see another at http://www.sciviews.org/_rgui/wiki/doku.php > (Phillippe Grosjean) > which is nominally geared toward beginners/GUI interfaces. > > I'm not saying I could do any better, but both of these look > as though they'd be pretty hard to get into if you were really > a beginner or intermediate R user looking for info ... Paul > John's Rtips (http://www.ku.edu/~pauljohn/R/Rtips.html) is actually > about the best example about there -- the flat hierarchy might not > work too well for a really big wiki, but having at least > a good first-level hierarchy set up (and making sure that > what new users see is not a lot of detail about how to extend > the wiki) seems really important. > >Sorry to criticize, but I am happy to start working > on populating a wiki -- but only if the structure is there > so that I can figure out where to put stuff and hope that > someone who needs it will ever be able to find it ... > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem installing from source: no CONTENTS files
> Brian D. Ripley, [EMAIL PROTECTED] > This will only happen if you installed R without HTML help > and then install a package *with* HTML help *and* do so into > a non-standard directory. That seems an arcane thing to do: > why do you want HTML help for some packages and not others? > You will end up with a partially functional system. > > The fix is simple: put '-' at the beginning of that line > (after the tab) in MakePkg. I've put a more complete > solution in R-devel. Thanks for the fix. I think the message is more general, though. What I want to do is install the package just with "vanilla help"-- the stuff that comes up in the pager. According to "RCMD INSTALL --help" the only options are "doc=none/normal/chtml/all"-- there's no "vanilla" or equivalent. If I do "doc=none" I don't get vanilla help. So "doc=normal" is required, and this tries to do HTML which I don't need. A vanilla-only option would be ideal, I guess. > > On Mon, 9 Jan 2006 [EMAIL PROTECTED] wrote: > > > I've just had the error below while trying to install a > package from > > source under R2.2.1 and Windows XP. I recall encountering this > > sporadically in the past. It is a pretty confusing message > and took me > > quite some time to figure out; I've seen queries about it on the R <> > > -- Making package debug <> installing > > indices > > cat: C:/R/RW2021/library/*/CONTENTS: No such file or directory <> > > be used? If not, a different error message would be handy. > > The error message is completely informative: why would you > want to change it? I should have said "an additional error message" instead of "a different...". It's pretty difficult for a user to track down where & why it is occurring and whether it matters-- accurate, yes, but not informative! Anyway, maybe otiose now (the more complete solution hasn't made it to the R-devel I got this morning, so I can't check yet). > > > I don't understand enough about makefiles to suggest a patch, > > unfortunately. > > A good learning project for you? true no doubt-- but just one out of so many ... :( Thanks Mark > > > > Mark Bravington > > CSIRO Mathematical & Information Sciences Marine Laboratory Castray > > Esplanade Hobart 7001 TAS > > > > ph (+61) 3 6232 5118 > > fax (+61) 3 6232 5012 > > mob (+61) 438 315 623 > > > > __ > > 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
