[Rd] help pages base R not rendered correctly?
Hi all,
Don't know if this is a known issue, but I couldn't find anything so I
report anyway. When checking eg ?qr in both RStudio and the naked R IDE,
the help page is rendered incorrectly. More specifically, any use of
\bold{...} is printed as is, rather than interpreted as bold. Same happens
on ?svd.
According to the manual Writing R Extensions, this should still be
recognized. When I try to use it in the help pages of my own packages,
\bold{} is interpreted correctly.
No idea what is going wrong and it's not that important, but I found it
curious enough to report.
Cheers
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help pages base R not rendered correctly?
On 23/05/2017 8:39 AM, Joris Meys wrote:
Hi all,
Don't know if this is a known issue, but I couldn't find anything so I
report anyway. When checking eg ?qr in both RStudio and the naked R IDE,
the help page is rendered incorrectly. More specifically, any use of
\bold{...} is printed as is, rather than interpreted as bold. Same happens
on ?svd.
In ?qr (and probably in ?svd), \bold is inside \eqn{}, so it is being
interpreted as LaTeX markup rather than Rd markup, and since no
alternative was given, is displayed as-is.
If you actually wanted it to display properly in HTML and ascii, the
current \eqn{\bold{Ax} = \bold{b}} would have to be written as something
like
\ifelse{latex}{\eqn{\bold{Ax} = \bold{b}}}{\bold{Ax} = \bold{b}}
which is pretty tedious to write, and it's not the only example on that
page. So I doubt if anyone will fix it.
According to the manual Writing R Extensions, this should still be
recognized. When I try to use it in the help pages of my own packages,
\bold{} is interpreted correctly.
You missed the part about \eqn.
Duncan Murdoch
No idea what is going wrong and it's not that important, but I found it
curious enough to report.
Cheers
Joris
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help pages base R not rendered correctly?
Hi Duncan,
that explains, thank you. If nobody finds the time to fix that, I might
give it a shot myself this summer. Barbeque is overrated.
Cheers
Joris
On Tue, May 23, 2017 at 3:10 PM, Duncan Murdoch
wrote:
> On 23/05/2017 8:39 AM, Joris Meys wrote:
>
>> Hi all,
>>
>> Don't know if this is a known issue, but I couldn't find anything so I
>> report anyway. When checking eg ?qr in both RStudio and the naked R IDE,
>> the help page is rendered incorrectly. More specifically, any use of
>> \bold{...} is printed as is, rather than interpreted as bold. Same happens
>> on ?svd.
>>
>
> In ?qr (and probably in ?svd), \bold is inside \eqn{}, so it is being
> interpreted as LaTeX markup rather than Rd markup, and since no alternative
> was given, is displayed as-is.
>
> If you actually wanted it to display properly in HTML and ascii, the
> current \eqn{\bold{Ax} = \bold{b}} would have to be written as something
> like
>
> \ifelse{latex}{\eqn{\bold{Ax} = \bold{b}}}{\bold{Ax} = \bold{b}}
>
> which is pretty tedious to write, and it's not the only example on that
> page. So I doubt if anyone will fix it.
>
>
>> According to the manual Writing R Extensions, this should still be
>> recognized. When I try to use it in the help pages of my own packages,
>> \bold{} is interpreted correctly.
>>
>
> You missed the part about \eqn.
>
> Duncan Murdoch
>
>
>
>> No idea what is going wrong and it's not that important, but I found it
>> curious enough to report.
>>
>> Cheers
>> Joris
>>
>>
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help pages base R not rendered correctly?
> On 23 May 2017, at 15:56 , Joris Meys wrote: > > Hi Duncan, > > that explains, thank you. If nobody finds the time to fix that, I might > give it a shot myself this summer. Barbeque is overrated. I beg to differ! Chances of rain are underestimated, though (in .be as in .dk, I suspect). ;-) -pd > > Cheers > Joris > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf
Hi Michael,
I posted something on this topic to R-devel several weeks ago, but never
got a response. My ultimate conclusion is that sprintf() isn't super
consistent in how it handles coercion: sometimes it'll coerce real to
integer without complaint, other times it won't. (My particular email had
to do with the vectors longer than 1 and their positioning vis-a-vis the
format string.) The safest thing is just to pass the right type. In this
case, sprintf('%d', as.integer(NA_real_)) works.
Best,
Evan
On Fri, May 19, 2017 at 9:23 AM, Michael Chirico
wrote:
> Consider
>
> #as.numeric for emphasis
> sprintf('%d', as.numeric(1))
> # [1] "1"
>
> vs.
>
> sprintf('%d', NA_real_)
>
> > Error in sprintf("%d", NA_real_) :
>
>invalid format '%d'; use format %f, %e, %g or %a for numeric object
> >
>
> I understand the error is correct, but if it works for other numeric input,
> why doesn't R just coerce NA_real_ to NA_integer_?
>
> Michael Chirico
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Evan Cortens, PhD
Institutional Analyst - Office of Institutional Analysis
Mount Royal University
403-440-6529
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] Ensure correct order of evaluation in macro
Hi Duncan, Would you merge this patch? I'm planning on sending larger patches in the next few days that fix other macros I've seen, but I figured​ it'd be best to start with a smaller patch. Thanks, Sahil __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf
I initially thought this is "documented behaviour". ?sprintf says:
Numeric variables with __exactly integer__ values will be coerced to
integer. (emphasis mine).
Turns out this only works when the first value is numeric and not NA, as
shown by the following example:
> sprintf("%d", as.numeric(c(NA,1)))
Error in sprintf("%d", as.numeric(c(NA, 1))) :
invalid format '%d'; use format %f, %e, %g or %a for numeric objects
> sprintf("%d", as.numeric(c(1,NA)))
[1] "1" "NA"
So the safest thing is indeed passing the right type, but the behaviour is
indeed confusing. I checked this on both Windows and Debian, and on both
systems I get the exact same response.
Cheers
Joris
On Tue, May 23, 2017 at 4:53 PM, Evan Cortens wrote:
> Hi Michael,
>
> I posted something on this topic to R-devel several weeks ago, but never
> got a response. My ultimate conclusion is that sprintf() isn't super
> consistent in how it handles coercion: sometimes it'll coerce real to
> integer without complaint, other times it won't. (My particular email had
> to do with the vectors longer than 1 and their positioning vis-a-vis the
> format string.) The safest thing is just to pass the right type. In this
> case, sprintf('%d', as.integer(NA_real_)) works.
>
> Best,
>
> Evan
>
> On Fri, May 19, 2017 at 9:23 AM, Michael Chirico <
> michaelchiri...@gmail.com>
> wrote:
>
> > Consider
> >
> > #as.numeric for emphasis
> > sprintf('%d', as.numeric(1))
> > # [1] "1"
> >
> > vs.
> >
> > sprintf('%d', NA_real_)
> >
> > > Error in sprintf("%d", NA_real_) :
> >
> >invalid format '%d'; use format %f, %e, %g or %a for numeric object
> > >
> >
> > I understand the error is correct, but if it works for other numeric
> input,
> > why doesn't R just coerce NA_real_ to NA_integer_?
> >
> > Michael Chirico
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
>
> --
> Evan Cortens, PhD
> Institutional Analyst - Office of Institutional Analysis
> Mount Royal University
> 403-440-6529
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf
Astute observation. And of course we should be passing integer when we use
%d. It's an edge case in how we printed ITime objects in data.table:
On Tue, May 23, 2017 at 11:53 AM, Joris Meys wrote:
> I initially thought this is "documented behaviour". ?sprintf says:
>
> Numeric variables with __exactly integer__ values will be coerced to
> integer. (emphasis mine).
>
> Turns out this only works when the first value is numeric and not NA, as
> shown by the following example:
>
> > sprintf("%d", as.numeric(c(NA,1)))
> Error in sprintf("%d", as.numeric(c(NA, 1))) :
> invalid format '%d'; use format %f, %e, %g or %a for numeric objects
> > sprintf("%d", as.numeric(c(1,NA)))
> [1] "1" "NA"
>
> So the safest thing is indeed passing the right type, but the behaviour is
> indeed confusing. I checked this on both Windows and Debian, and on both
> systems I get the exact same response.
>
> Cheers
> Joris
>
> On Tue, May 23, 2017 at 4:53 PM, Evan Cortens wrote:
>
>> Hi Michael,
>>
>> I posted something on this topic to R-devel several weeks ago, but never
>> got a response. My ultimate conclusion is that sprintf() isn't super
>> consistent in how it handles coercion: sometimes it'll coerce real to
>> integer without complaint, other times it won't. (My particular email had
>> to do with the vectors longer than 1 and their positioning vis-a-vis the
>> format string.) The safest thing is just to pass the right type. In this
>> case, sprintf('%d', as.integer(NA_real_)) works.
>>
>> Best,
>>
>> Evan
>>
>> On Fri, May 19, 2017 at 9:23 AM, Michael Chirico <
>> michaelchiri...@gmail.com>
>> wrote:
>>
>> > Consider
>> >
>> > #as.numeric for emphasis
>> > sprintf('%d', as.numeric(1))
>> > # [1] "1"
>> >
>> > vs.
>> >
>> > sprintf('%d', NA_real_)
>> >
>> > > Error in sprintf("%d", NA_real_) :
>> >
>> >invalid format '%d'; use format %f, %e, %g or %a for numeric object
>> > >
>> >
>> > I understand the error is correct, but if it works for other numeric
>> input,
>> > why doesn't R just coerce NA_real_ to NA_integer_?
>> >
>> > Michael Chirico
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>> --
>> Evan Cortens, PhD
>> Institutional Analyst - Office of Institutional Analysis
>> Mount Royal University
>> 403-440-6529
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> tel : +32 (0)9 264 61 79 <+32%209%20264%2061%2079>
> joris.m...@ugent.be
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf
https://github.com/Rdatatable/data.table/issues/2171
The fix was easy, it's just surprising to see the behavior change almost on
a whim. Just wanted to point it out in case this is unknown behavior, but
Evan seems to have found this as well.
On Tue, May 23, 2017 at 12:00 PM, Michael Chirico wrote:
> Astute observation. And of course we should be passing integer when we use
> %d. It's an edge case in how we printed ITime objects in data.table:
>
>
> On Tue, May 23, 2017 at 11:53 AM, Joris Meys wrote:
>
>> I initially thought this is "documented behaviour". ?sprintf says:
>>
>> Numeric variables with __exactly integer__ values will be coerced to
>> integer. (emphasis mine).
>>
>> Turns out this only works when the first value is numeric and not NA, as
>> shown by the following example:
>>
>> > sprintf("%d", as.numeric(c(NA,1)))
>> Error in sprintf("%d", as.numeric(c(NA, 1))) :
>> invalid format '%d'; use format %f, %e, %g or %a for numeric objects
>> > sprintf("%d", as.numeric(c(1,NA)))
>> [1] "1" "NA"
>>
>> So the safest thing is indeed passing the right type, but the behaviour
>> is indeed confusing. I checked this on both Windows and Debian, and on both
>> systems I get the exact same response.
>>
>> Cheers
>> Joris
>>
>> On Tue, May 23, 2017 at 4:53 PM, Evan Cortens
>> wrote:
>>
>>> Hi Michael,
>>>
>>> I posted something on this topic to R-devel several weeks ago, but never
>>> got a response. My ultimate conclusion is that sprintf() isn't super
>>> consistent in how it handles coercion: sometimes it'll coerce real to
>>> integer without complaint, other times it won't. (My particular email had
>>> to do with the vectors longer than 1 and their positioning vis-a-vis the
>>> format string.) The safest thing is just to pass the right type. In this
>>> case, sprintf('%d', as.integer(NA_real_)) works.
>>>
>>> Best,
>>>
>>> Evan
>>>
>>> On Fri, May 19, 2017 at 9:23 AM, Michael Chirico <
>>> michaelchiri...@gmail.com>
>>> wrote:
>>>
>>> > Consider
>>> >
>>> > #as.numeric for emphasis
>>> > sprintf('%d', as.numeric(1))
>>> > # [1] "1"
>>> >
>>> > vs.
>>> >
>>> > sprintf('%d', NA_real_)
>>> >
>>> > > Error in sprintf("%d", NA_real_) :
>>> >
>>> >invalid format '%d'; use format %f, %e, %g or %a for numeric object
>>> > >
>>> >
>>> > I understand the error is correct, but if it works for other numeric
>>> input,
>>> > why doesn't R just coerce NA_real_ to NA_integer_?
>>> >
>>> > Michael Chirico
>>> >
>>> > [[alternative HTML version deleted]]
>>> >
>>> > __
>>> > R-devel@r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >
>>>
>>>
>>>
>>> --
>>> Evan Cortens, PhD
>>> Institutional Analyst - Office of Institutional Analysis
>>> Mount Royal University
>>> 403-440-6529
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>>
>> --
>> Joris Meys
>> Statistical consultant
>>
>> Ghent University
>> Faculty of Bioscience Engineering
>> Department of Mathematical Modelling, Statistics and Bio-Informatics
>>
>> tel : +32 (0)9 264 61 79 <+32%209%20264%2061%2079>
>> joris.m...@ugent.be
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistency in handling of numeric input with %d by sprintf
Yes, what Joris posts about is exactly what I noted in my March 9th post to
R-devel. The behaviour is sort of documented, but not in the clearest
manner (in my opinion). Like I say, my ultimate conclusion was that the
silent coercion of numerics to integers by sprintf() was a handy
convenience, but not one that should be relied about to always work
predictably.
On Tue, May 23, 2017 at 10:02 AM, Michael Chirico wrote:
> https://github.com/Rdatatable/data.table/issues/2171
>
> The fix was easy, it's just surprising to see the behavior change almost
> on a whim. Just wanted to point it out in case this is unknown behavior,
> but Evan seems to have found this as well.
>
> On Tue, May 23, 2017 at 12:00 PM, Michael Chirico <
> michaelchiri...@gmail.com> wrote:
>
>> Astute observation. And of course we should be passing integer when we
>> use %d. It's an edge case in how we printed ITime objects in data.table:
>>
>>
>> On Tue, May 23, 2017 at 11:53 AM, Joris Meys wrote:
>>
>>> I initially thought this is "documented behaviour". ?sprintf says:
>>>
>>> Numeric variables with __exactly integer__ values will be coerced to
>>> integer. (emphasis mine).
>>>
>>> Turns out this only works when the first value is numeric and not NA, as
>>> shown by the following example:
>>>
>>> > sprintf("%d", as.numeric(c(NA,1)))
>>> Error in sprintf("%d", as.numeric(c(NA, 1))) :
>>> invalid format '%d'; use format %f, %e, %g or %a for numeric objects
>>> > sprintf("%d", as.numeric(c(1,NA)))
>>> [1] "1" "NA"
>>>
>>> So the safest thing is indeed passing the right type, but the behaviour
>>> is indeed confusing. I checked this on both Windows and Debian, and on both
>>> systems I get the exact same response.
>>>
>>> Cheers
>>> Joris
>>>
>>> On Tue, May 23, 2017 at 4:53 PM, Evan Cortens
>>> wrote:
>>>
Hi Michael,
I posted something on this topic to R-devel several weeks ago, but never
got a response. My ultimate conclusion is that sprintf() isn't super
consistent in how it handles coercion: sometimes it'll coerce real to
integer without complaint, other times it won't. (My particular email
had
to do with the vectors longer than 1 and their positioning vis-a-vis the
format string.) The safest thing is just to pass the right type. In this
case, sprintf('%d', as.integer(NA_real_)) works.
Best,
Evan
On Fri, May 19, 2017 at 9:23 AM, Michael Chirico <
michaelchiri...@gmail.com>
wrote:
> Consider
>
> #as.numeric for emphasis
> sprintf('%d', as.numeric(1))
> # [1] "1"
>
> vs.
>
> sprintf('%d', NA_real_)
>
> > Error in sprintf("%d", NA_real_) :
>
>invalid format '%d'; use format %f, %e, %g or %a for numeric object
> >
>
> I understand the error is correct, but if it works for other numeric
input,
> why doesn't R just coerce NA_real_ to NA_integer_?
>
> Michael Chirico
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Evan Cortens, PhD
Institutional Analyst - Office of Institutional Analysis
Mount Royal University
403-440-6529
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>> --
>>> Joris Meys
>>> Statistical consultant
>>>
>>> Ghent University
>>> Faculty of Bioscience Engineering
>>> Department of Mathematical Modelling, Statistics and Bio-Informatics
>>>
>>> tel : +32 (0)9 264 61 79 <+32%209%20264%2061%2079>
>>> joris.m...@ugent.be
>>> ---
>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>>
>>
>>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] Ensure correct order of evaluation in macro
On 23/05/2017 11:47 AM, Sahil Kang wrote: Hi Duncan, Would you merge this patch? I'm planning on sending larger patches in the next few days that fix other macros I've seen, but I figured​ it'd be best to start with a smaller patch. No, I generally try to leave the macro stuff to others. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Allow dot in RHS of update.formula's old formula
Feature request: I want to use update.formula to subtract an intercept (or other) term from a formula with a dot on the RHS. However, as this causes an error, I propose a patch below. Thus, I want: > update.formula(y ~ ., ~ . -1) [1] y ~ . - 1 Instead I get this error: Error in terms.formula(tmp, simplify = TRUE) : '.' in formula and no 'data' argument While the error message isn't especially helpful (as I *cannot* currently pass in a data argument), the problem is that terms.formula inside update.formula does not allow a dot in the RHS of 'old' unless either a 'data' argument is passed in or 'allowDotAsName=TRUE'. Thus, I'd like to suggest this change to update.formula to allow a dot in the RHS of old without (I believe) impacting any other behavior. -out <- formula(terms.formula(tmp, simplify = TRUE)) +out <- formula(terms.formula(tmp, simplify = TRUE, allowDotAsName=TRUE)) If this is undesirable for some reason, then alternatively the dots argument of update.formula could be passed to terms.formula so the user could pass in either 'data' or 'allowDotAsName=TRUE' themselves (though as I cannot think of any reason the user would prefer 'allowDotAsName=FALSE', this is not my preference). -out <- formula(terms.formula(tmp, simplify = TRUE)) +out <- formula(terms.formula(tmp, simplify = TRUE, ...)) >From my reading of the Details section of ?update.formula, it seems as if this >suggestion is consistent with the current documentation, as no mention is made >of dots in the RHS of 'old', and no mention is made of why this behavior >should be otherwise prohibited. If neither change is desirable for some >reason, then the update.formula documentation should at least point out this >exception (e.g. "... and substitutes the _rhs_ of the 'old' formula for any >occurrence of '.' on the right of 'new' *except if there is a dot in the _rhs_ >of 'old'*." Thanks, Robert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Getting an R bugzilla account
Hi All, I have a fix to this bug ( https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16454) and would like to submit a patch to the bug report on Bugzilla. I'd also like to start going through some of the other Windows-specific issues and start fixing those. The bug submission instructions indicate that I should ask here for a Bugzilla account. Is that still the correct procedure? Thanks! Nathan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting an R bugzilla account
Thanks for your help Nathan. I have added a bugzilla account for you. Martyn On Tue, 2017-05-23 at 21:02 +, Nathan Sosnovske via R-devel wrote: > Hi All, > > I have a fix to this bug ( https://bugs.r-project.org/bugzilla3/show_ > bug.cgi?id=16454) and would like to submit a patch to the bug report > on Bugzilla. I'd also like to start going through some of the other > Windows-specific issues and start fixing those. The bug submission > instructions indicate that I should ask here for a Bugzilla account. > Is that still the correct procedure? > > Thanks! > > Nathan > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
