Re: [Rd] R Include File Guards

[Prof Brian Ripley]

What is the `bug' here which you suggest reporting?

We have already established that leading underscores are NOT `illegal', 
just reserved and possibly ineffective according to the C99 standard 
(although we don't have any evidence of that being followed by an actual 
compiler). Given that the system includes on all three of my OSes use 
guards with leading underscores, they were VERY unlikely to be `illegal' 
as you stated.  (Looking in /usr/local/include shows that they are very 
widely used in other projects.)

Is there any known platform on which there is a consequential problem? 
If not (and we have no evidence), we do not play around with non-bugs in 
patch releases.

Some adjustments have been made in the development version of R.
BTW: not all files in R_ext are part of the API: however GraphicsDevice.h 
and GraphicsEngine.h are and they are now compatible with C++ and have 
guards.

On Wed, 15 Jun 2005, Paul Roebuck wrote:

> On Wed, 18 May 2005, Peter Dalgaard wrote:
>
>> Paul Roebuck <[EMAIL PROTECTED]> writes:
>>
>>> R 2.1.0/src/include from 2005/04/18 download
>>>
>>> Naming inconsistent for guards as well but that's pedantic.
>>> Simple convention:
>>>   file 
>>> #ifndef R_FOO_H
>>>   file 
>>> #ifndef R_EXT_BAR_H
>>>
>>> Missing guards:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>> Illegal Guards (leading underscore):
>>> 
>>> 
>>> 
>>
>> Thanks. The ones outside R_ext, except Rinternals.h, are not part of 
the
>> API, so it is not a bug that there are no guards - could still be a
>> good idea to have them of course. libextern.h explicitly says that you
>> shouldn't disallow including it more than once. So the ones with real
>> problems would be
>>
>> 
>> 
>> 
>> 
>>
>> 
>> 
>>
>> What's illegal about leading underscores, BTW?
>>
>
> I downloaded the R-patched for 2005/06/14 and noticed that
> the guards were never fixed. Should a bug report have been
> opened instead of simply noting them here?
>


-- 
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] hist.default documentation

[Deepayan Sarkar]

I think there are a couple of things in ?hist that are not quite as
clear as they could be.

(1)

  freq: logical; if 'TRUE', the histogram graphic is a representation
  of frequencies, the 'counts' component of the result; if
  'FALSE', _relative_ frequencies ("probabilities"), component
  'density', are plotted.   Defaults to 'TRUE' _iff_ 'breaks'
  are equidistant (and 'probability' is not specified).
 
Unless I'm missing something, the 'density' component is NOT relative
frequency or 'probability' in any reasonable sense, country-specific
biases notwithstanding, except in the very special case where
all(diff(breaks) == 1). Thus, the above description is confusing and
probably even wrong.

Also, it seems to me that hist cannot draw a relative frequency
histogram at all (which is not a bad thing, but it's of course very
important to the undergrads we're teaching intro stats and R to). This
should be explicitly mentioned.

(2) 

  breaks: one of:

 ...
 *  a single number giving the number of cells for the
histogram,
 ...

This is not quite true. 'breaks' is used in 'pretty', so it's more a
suggestion than an exact specification. I'm not sure whether or not
the behaviour should be changed (what's the point of having ``pretty''
breakpoints anyway?), but if not, the documentation should be
clarified.

I'll be happy to provide a patch if these changes are considered reasonable.

Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] hist.default documentation

[Duncan Murdoch]

On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
> I think there are a couple of things in ?hist that are not quite as
> clear as they could be.
> 
> (1)
> 
>   freq: logical; if 'TRUE', the histogram graphic is a representation
>   of frequencies, the 'counts' component of the result; if
>   'FALSE', _relative_ frequencies ("probabilities"), component
>   'density', are plotted.   Defaults to 'TRUE' _iff_ 'breaks'
>   are equidistant (and 'probability' is not specified).
>  
> Unless I'm missing something, the 'density' component is NOT relative
> frequency or 'probability' in any reasonable sense, country-specific
> biases notwithstanding, except in the very special case where
> all(diff(breaks) == 1). Thus, the above description is confusing and
> probably even wrong.

I agree.

> Also, it seems to me that hist cannot draw a relative frequency
> histogram at all (which is not a bad thing, but it's of course very
> important to the undergrads we're teaching intro stats and R to). This
> should be explicitly mentioned.

I'm not sure about this.  Is it really worth mentioning something if you 
can't do it?  Are you thinking of just giving a reference to barplot?

> (2) 
> 
>   breaks: one of:
> 
>  ...
>  *  a single number giving the number of cells for the
> histogram,
>  ...
> 
> This is not quite true. 'breaks' is used in 'pretty', so it's more a
> suggestion than an exact specification. I'm not sure whether or not
> the behaviour should be changed (what's the point of having ``pretty''
> breakpoints anyway?), but if not, the documentation should be
> clarified.

I like the pretty breakpoints. It is good to label the breakpoints, and 
ugly to have labels at other than pretty points.  I'd clarify by 
changing "giving" to "suggesting".

> I'll be happy to provide a patch if these changes are considered reasonable.

Please do.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] hist.default documentation

[Deepayan Sarkar]

On 6/17/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
> > I think there are a couple of things in ?hist that are not quite as
> > clear as they could be.
> >
> > (1)
> >
> >   freq: logical; if 'TRUE', the histogram graphic is a representation
> >   of frequencies, the 'counts' component of the result; if
> >   'FALSE', _relative_ frequencies ("probabilities"), component
> >   'density', are plotted.   Defaults to 'TRUE' _iff_ 'breaks'
> >   are equidistant (and 'probability' is not specified).
> >
> > Unless I'm missing something, the 'density' component is NOT relative
> > frequency or 'probability' in any reasonable sense, country-specific
> > biases notwithstanding, except in the very special case where
> > all(diff(breaks) == 1). Thus, the above description is confusing and
> > probably even wrong.
> 
> I agree.
> 
> > Also, it seems to me that hist cannot draw a relative frequency
> > histogram at all (which is not a bad thing, but it's of course very
> > important to the undergrads we're teaching intro stats and R to). This
> > should be explicitly mentioned.
> 
> I'm not sure about this.  Is it really worth mentioning something if you
> can't do it?  Are you thinking of just giving a reference to barplot?

Not mentioning it is fine.

> > (2)
> >
> >   breaks: one of:
> >
> >  ...
> >  *  a single number giving the number of cells for the
> > histogram,
> >  ...
> >
> > This is not quite true. 'breaks' is used in 'pretty', so it's more a
> > suggestion than an exact specification. I'm not sure whether or not
> > the behaviour should be changed (what's the point of having ``pretty''
> > breakpoints anyway?), but if not, the documentation should be
> > clarified.
> 
> I like the pretty breakpoints. It is good to label the breakpoints, and
> ugly to have labels at other than pretty points.  I'd clarify by
> changing "giving" to "suggesting".

Actually, I missed the remark just below this:

  In the last three cases the number is a suggestion only.

so this is fine as it is.

> > I'll be happy to provide a patch if these changes are considered reasonable.
> 
> Please do.

Here's the output of svn diff. Is this a reasonable way of providing a patch?

Index: hist.Rd
===
--- hist.Rd (revision 34748)
+++ hist.Rd (working copy)
@@ -28,9 +28,9 @@
   }
   \item{freq}{logical; if \code{TRUE}, the histogram graphic is a
 representation of frequencies, the \code{counts} component of
-the result; if \code{FALSE}, \emph{relative} frequencies
-(\dQuote{probabilities}), component \code{density},
-are plotted.   Defaults to \code{TRUE} \emph{iff} \code{breaks} are
+the result; if \code{FALSE}, probability densities, component
+\code{density}, are plotted (so that the histogram has a total area
+of one).  Defaults to \code{TRUE} \emph{iff} \code{breaks} are
 equidistant (and \code{probability} is not specified).}
   \item{probability}{an \emph{alias} for \code{!freq}, for S compatibility.}
   \item{include.lowest}{logical; if \code{TRUE}, an \code{x[i]} equal to

Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] hist.default documentation

[Duncan Murdoch]

Thanks, I've committed the change.

Duncan Murdoch

On 6/17/2005 10:30 AM, Deepayan Sarkar wrote:
> On 6/17/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
>> > I think there are a couple of things in ?hist that are not quite as
>> > clear as they could be.
>> >
>> > (1)
>> >
>> >   freq: logical; if 'TRUE', the histogram graphic is a representation
>> >   of frequencies, the 'counts' component of the result; if
>> >   'FALSE', _relative_ frequencies ("probabilities"), component
>> >   'density', are plotted.   Defaults to 'TRUE' _iff_ 'breaks'
>> >   are equidistant (and 'probability' is not specified).
>> >
>> > Unless I'm missing something, the 'density' component is NOT relative
>> > frequency or 'probability' in any reasonable sense, country-specific
>> > biases notwithstanding, except in the very special case where
>> > all(diff(breaks) == 1). Thus, the above description is confusing and
>> > probably even wrong.
>> 
>> I agree.
>> 
>> > Also, it seems to me that hist cannot draw a relative frequency
>> > histogram at all (which is not a bad thing, but it's of course very
>> > important to the undergrads we're teaching intro stats and R to). This
>> > should be explicitly mentioned.
>> 
>> I'm not sure about this.  Is it really worth mentioning something if you
>> can't do it?  Are you thinking of just giving a reference to barplot?
> 
> Not mentioning it is fine.
> 
>> > (2)
>> >
>> >   breaks: one of:
>> >
>> >  ...
>> >  *  a single number giving the number of cells for the
>> > histogram,
>> >  ...
>> >
>> > This is not quite true. 'breaks' is used in 'pretty', so it's more a
>> > suggestion than an exact specification. I'm not sure whether or not
>> > the behaviour should be changed (what's the point of having ``pretty''
>> > breakpoints anyway?), but if not, the documentation should be
>> > clarified.
>> 
>> I like the pretty breakpoints. It is good to label the breakpoints, and
>> ugly to have labels at other than pretty points.  I'd clarify by
>> changing "giving" to "suggesting".
> 
> Actually, I missed the remark just below this:
> 
>   In the last three cases the number is a suggestion only.
> 
> so this is fine as it is.
> 
>> > I'll be happy to provide a patch if these changes are considered 
>> > reasonable.
>> 
>> Please do.
> 
> Here's the output of svn diff. Is this a reasonable way of providing a patch?
> 
> Index: hist.Rd
> ===
> --- hist.Rd (revision 34748)
> +++ hist.Rd (working copy)
> @@ -28,9 +28,9 @@
>}
>\item{freq}{logical; if \code{TRUE}, the histogram graphic is a
>  representation of frequencies, the \code{counts} component of
> -the result; if \code{FALSE}, \emph{relative} frequencies
> -(\dQuote{probabilities}), component \code{density},
> -are plotted.   Defaults to \code{TRUE} \emph{iff} \code{breaks} are
> +the result; if \code{FALSE}, probability densities, component
> +\code{density}, are plotted (so that the histogram has a total area
> +of one).  Defaults to \code{TRUE} \emph{iff} \code{breaks} are
>  equidistant (and \code{probability} is not specified).}
>\item{probability}{an \emph{alias} for \code{!freq}, for S compatibility.}
>\item{include.lowest}{logical; if \code{TRUE}, an \code{x[i]} equal to
> 
> Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (PR#7951) DispatchOrEval missing in do_isfinite and do_isinfinite

[lars]

Hi,

OK, if you try to explicitly make them generic, you are told that they 
are implicitly already generic:

 > setGeneric("is.finite", function(from, ...) standardGeneric("is.finite"))
Error in setGeneric("is.finite", function(from, ...) 
standardGeneric("is.finite")) :
"is.finite" is a primitive function;  methods can be defined, but 
the generic function is implicit, and can't be changed.

If you query about its genericness before you define you own generic, 
you get:

 > isGeneric("is.finite")
[1] FALSE

But after you define you own generic, you get:

 > setMethod("is.finite", signature(x="TS"),
+   function(x) {
+  Data(x) = callNextMethod()
+  x
+   })
[1] "is.finite"

 > isGeneric("is.finite")
[1] TRUE

This all makes some sense, but I am not familiar enough with he 
internals to explain exactly why it is done this way. I think you will 
fine that 'is.nan' behave exactly the same way.

Thanks,
Lars


Prof Brian Ripley wrote:

> These functions are not generic according to the help page.
> The same page says explicitly that is.nan is generic.
>
> Where did you get the (false) idea that they were generic?
>
> On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Lars Hansen
>> Version: 2.1.0
>> OS: SunOS 5.8
>> Submission from: (NULL) (207.66.36.189)
>>
>>
>> Hi,
>>
>> S4 method displacth does not work for the two generic functions 
>> 'is.finite' and 'is.infinite'. It turns out that the C functions 
>> 'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a 
>> call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the 
>> problem. My functions no look like this:
>>
>> Form coerce.c:
>>
>> SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>> {
>>SEXP ans, x, names, dims;
>>int i, n;
>>
>>if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
>>return(ans);
>>
>>checkArity(op, args);
>>...
>>
>> SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>> {
>>SEXP ans, x, names, dims;
>>double xr, xi;
>>int i, n;
>>
>>if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
>>return(ans);
>>
>>checkArity(op, args);
>>...
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R Include File Guards

[Paul Roebuck]

On Fri, 17 Jun 2005, Prof Brian Ripley wrote:

> On Wed, 15 Jun 2005, Paul Roebuck wrote:
>
> > On Wed, 18 May 2005, Peter Dalgaard wrote:
> >
> >> Paul Roebuck <[EMAIL PROTECTED]> writes:
> >>
> >>> R 2.1.0/src/include from 2005/04/18 download
> >>>
> >>> Naming inconsistent for guards as well but that's pedantic.
> >>> Simple convention:
> >>>   file 
> >>> #ifndef R_FOO_H
> >>>   file 
> >>> #ifndef R_EXT_BAR_H
> >>>
> >>> Missing guards:
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>
> >>>
> >>> Illegal Guards (leading underscore):
> >>> 
> >>> 
> >>> 
> >>
> >> Thanks. The ones outside R_ext, except Rinternals.h, are not part of
> the
> >> API, so it is not a bug that there are no guards - could still be a
> >> good idea to have them of course. libextern.h explicitly says that you
> >> shouldn't disallow including it more than once. So the ones with real
> >> problems would be
> >>
> >> 
> >> 
> >> 
> >> 
> >>
> >> 
> >> 
> >>
> >> What's illegal about leading underscores, BTW?
> >>
> >
> > I downloaded the R-patched for 2005/06/14 and noticed that
> > the guards were never fixed. Should a bug report have been
> > opened instead of simply noting them here?
>
> What is the `bug' here which you suggest reporting?
>
> We have already established that leading underscores are NOT `illegal',
> just reserved and possibly ineffective according to the C99 standard
> (although we don't have any evidence of that being followed by an actual
> compiler). Given that the system includes on all three of my OSes use
> guards with leading underscores, they were VERY unlikely to be `illegal'
> as you stated.  (Looking in /usr/local/include shows that they are very
> widely used in other projects.)

Not sure when "we" established that. I was asked to provide
information about why it was illegal and I did so (per three OS
vendors) but nothing further was discussed. They are illegal exactly
because they are reserved for C compiler implementation vendors.
In essence, only implementation vendors are allowed to have header
files with leading underscores prepended to the guard names; thus
this is exactly the reason the system header files are done that way.
System headers use the leading underscore convention so the vendor is
free to add their own header files without causing problems for
existing user source. Here the situation is reversed as R has header
files that would cease to be included if a vendor added a header file
using the same guard.

As R Core is not a C compiler vendor, it is illegal usage.
Can one find other projects with include file guards with leading
underscores? Of course. Many people drive faster than the posted
speed limit - often without consequence.







> Is there any known platform on which there is a consequential problem?
> If not (and we have no evidence), we do not play around with non-bugs in
> patch releases.

Fair enough.

> Some adjustments have been made in the development version of R.
> BTW: not all files in R_ext are part of the API: however
> GraphicsDevice.h and GraphicsEngine.h are and they are now
> compatible with C++ and have guards.

Thank you.



As an aside, has it ever been advanced that these files
not part of the API have a different naming scheme? Back
in the day, Motif had a convention where they appended
a capital P (for private, I assume) to the file's basename.

Public header:
#include 
Private to the implementation header:
#include 

One could include the private heaers in code with the full
knowledge that the next release (of Motif) quite possibly
was going to break that code. :)

--
SIGSIG -- signature too long (core dumped)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] loess returns different standard errors for identical models (PR#7956)

[btyner]

Full_Name: Benjamin Tyner
Version: 2.1.0, 4/18/2005
OS: i686-redhat-linux-gnu
Submission from: (NULL) (4.64.8.220)


# Just run my.test() below in a newly opened R session. Once too many models
have been fit (~20 on my system), the computed standard error jumps to a
different value. This is (superficially) due to a different residual sum of
squares, not a different one.delta. No other aspect of the fit is affected, just
the computed value of s (I've run extensive testing with all.equal() to make
sure). Issuing a garbage collection before doing a loess fit appears to "solve"
the problem, which makes me think this is not a problem in loessc.c or loessf.f.
My point is that a few loess fits in one session should not cause the estimated
standard error computation go awry with no warning.

y<-rnorm(50)
x<-seq(0,1,length=50)
my.test<-function(){
counter<-0
go<-0
new.s<-0
while(go<2){
counter<-counter+1
old.s<-new.s
fit<-loess(y~x,family="symmetric")
new.s<-fit$s
if(new.s!=old.s)go<-go+1
print(paste("s = ",fit$s))
}
print(paste("Fit number ",counter," is different!",sep=""))
}

# If there does turn out to be a way to fix this is loessc.c or loessf.f, I
would be happy to collaborate on that.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Ambiguous address warning

[MMDF]

Mail addressed to

"[EMAIL PROTECTED]"

was ambiguous, but was delivered to

John_G_Dorsey (john)

The name "john" also matched the following users

Full name (login name)

Andrew_John (aj14)
Bonnie_John (bej)

To avoid this warning message in the future, address the mail as

"[EMAIL PROTECTED]"

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel