Re: [Rd] (PR#8049) add1.lm and add1.glm not handling weights and
David, Thanks. The reason add1.lm (and drop1.lm) do not support offsets is that lm did not when they were written, and the person who added offsets to lm did not change them. (I do wish they had not added an offset arg and just used the formula as in S's glm.) That is easy to add. For the other point, some care is needed if 'x' is supplied and the upper scope reduces the number of points. We can try harder, but your usage does give a warning and perhaps that needs to be an error in this case. Brian On Thu, 4 Aug 2005 [EMAIL PROTECTED] wrote: > I am using R 2.1.1 under Mac OS 10.3.9. > > Two related problems (see notes 1. and 2. below) are illustrated by > results of the following: > > y <- rnorm(10) > x <- z <- 1:10 > is.na(x[9]) <- TRUE > > lm0 <- lm(y ~ 1) > lm1 <- lm(y ~ 1, weights = rep(1, 10)) > > add1(lm0, scope = ~ x) ## works ok > add1(lm1, scope = ~ x) ## error > > lm2 <- lm(y ~ 1, offset = 1:10) > > add1(lm0, scope = ~ z) ## works ok > add1(lm2, scope = ~ z) ## gives incorrect results (ignores the offset) > > glm0 <- glm(y ~ 1) > glm1 <- glm(y ~ 1, weights = rep(1, 10)) > glm2 <- glm(y ~ 1, offset = rep(0, 10)) > > add1(glm0, scope = ~ x) ## error > add1(glm1, scope = ~ x) ## error > add1(glm2, scope = ~ x) ## error > > > > As I see it, the two problems are: > > 1. add1.lm ignores any offset present in its "object" argument. > > 2. add1.lm and add1.glm both take weights directly from their "object" > argument, and add1.glm also does the same for any offset that is > present. But this does not work when the upper scope includes missing > values and na.omit is used: the weights (and offset) then have the > wrong length. They should presumably be extracted instead from the > reduced model frame. > > > If I can be of help in fixing these things, please let me know. But I > don't want to make things worse, or to duplicate anyone else's work. I > don't see this fixed in the bug-fix list at > https://svn.r-project.org/R/trunk/NEWS > but I haven't checked whether the same problems are in the current > r-devel. > > David > > __ > 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] call fortran in R
On 04/08/2005, at 8:00 PM, Sebastien Durand wrote: > I used a mac G5, R.2.1.1, and G77 3.4.4 and I would like to use and > call a fortran subroutine. > The trouble is that it seems I am not able to correctly load the > compiled code. . > base > 2 /Library/Frameworks/R.framework/Resources/library/grDevices/libs/ > grDevices.so > 3 /Library/Frameworks/R.framework/Resources/library/stats/ > libs/stats.so > 4 /Library/Frameworks/R.framework/Resources/library/methods/libs/ > methods.so > 5 /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so > > Dynamic.Lookup > 1 FALSE > 2 FALSE > 3 FALSE > 4 FALSE > 5TRUE I really wish someone would make these issues clear in MacOS R documentation. MacOS X 10.3 Panther uses gcc-3.3 as its default compiler. The R binary is built with gcc-3.3 and g77 3.4 so that it will run on Panther. MacOS X 10.4 Tiger uses gcc-4.00 as its default compiler. This causes two problems. 1. Fortran objects built with g77 cannot be linked with C/C++ objects built with gcc-4.0. So an R package with a mixture of C and Fortran code will very likely fail at some point. 2. Even if you specifically invoke gcc-3.3 and g77 the code will still fail to link because it needs a symlink /usr/lib/ libcc_dynamic.dylib which points to libgcc.a. This link is missing if the default gcc-4.0 is the selected compiler. (It is missing because it does not work with gcc-4). If you want to build Fortran source packages on Tiger using the R binary distribution, you need to to do 'sudo gcc_select 3.3' That command will make gcc-3.3 the default compiler and reinstate the symlink, which recreates the environment in which the R binary was built. You can always go back to gcc-4.0 with 'sudo gcc_select 4.0'. Bill Northcott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 generating function
Can someone explain what the problem is when I use the
generating function? And how to get debug() to stop in
the Superclass initialize method?
source -
setClass("Superclass",
representation(id = "character"),
contains = "VIRTUAL")
setMethod("initialize",
signature(.Object = "Superclass"),
function(.Object, id = "") {
cat("initialize (Superclass)", "\n")
if (length(id) > 0) {
cat("\tid =", id, "\n")
[EMAIL PROTECTED] <- id
}
.Object
})
setClass("Subclass",
contains = "Superclass")
setMethod("initialize",
signature(.Object = "Subclass"),
function(.Object, ...) {
cat("initialize (Subclass)", "\n")
cat("\t... =");str(list(...));cat("\n")
callNextMethod(.Object, ...)
})
Subclass <- function(id = "") {
new("Subclass", id = id)
}
cat("*** Create class using new() ***\n")
str(new("Subclass", id = "test1"))
cat("*** Create class using generating function ***\n")
str(Subclass(id = "test2"))
output -
*** Create class using new() ***
initialize (Subclass)
... =List of 1
$ id: chr "test1"
initialize (Superclass)
id = test1
Formal class 'Subclass' [package ".GlobalEnv"] with 1 slots
..@ id: chr "test1"
*** Create class using generating function ***
initialize (Subclass)
... =List of 1
$ id: chr "test2"
initialize (Superclass)
Error in .local(.Object, ...) : Object "id" not found
Thanks
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check failing to warn when it should
> "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> on Wed, 3 Aug 2005 13:52:32 -0500 writes:
DeepS> Hi, I recently made changes to lattice code which
DeepS> needed changes in many man pages as well. Before I
DeepS> made the appropriate changes, R CMD check was
DeepS> flagging most of the problems correctly, except for
DeepS> the man page for tmd. I have created a toy package
DeepS> that shows this, available at
DeepS> http://www.stat.wisc.edu/~deepayan/R/tmdprob_0.12-2.tar.gz
DeepS> This passes R CMD check on R 2.1.0 and r-devel from
DeepS> August 1, but it shouldn't because the code and
DeepS> documentation are inconsistent.
It's because you use \synopsis{}.
This basically breaks all 'codoc' checking and is the reason
we (mainly Kurt, but I completely agree with him) have been
thinking about deprecating its use -- possibly using a
substitute for the few cases that might need something like it.
Kurt and I (at least) would very strongly advocate not to use
\synopsis{}, and hence writing functions and methods in a way
that can be well documented with exact \usage{}.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] object.size() bug?
> "Paul" == Paul Roebuck <[EMAIL PROTECTED]>
> on Thu, 4 Aug 2005 00:29:03 -0500 (CDT) writes:
Paul> Can someone confirm the following as a problem:
Yes, I can. No promiss for a fix in the very near future
though.
Martin Maechler, ETH Zurich
>> Can someone confirm the following as a problem:
>>
>> R> setClass("Foo", representation(.handle = "externalptr"))
>> R> object.size(new("Foo"))
>> Error in object.size(new("Foo")) : object.size: unknown type 22
>> R> R.version.string
>> [1] "R version 2.1.1, 2005-06-20"
>>
>> R-2.1.1/src/include/Rinternals.h
>> #define EXTPTRSXP 22/* external pointer */
>>
>> R-2.1.1/src/main/size.c:
>> objectsize(SEXP s) has no case for external pointers
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] object.size() bug?
Would it make sense for 'object.size()' to do the same thing for
external pointers as it does for environments?
-roger
Martin Maechler wrote:
>>"Paul" == Paul Roebuck <[EMAIL PROTECTED]>
>>on Thu, 4 Aug 2005 00:29:03 -0500 (CDT) writes:
>
>
> Paul> Can someone confirm the following as a problem:
>
> Yes, I can. No promiss for a fix in the very near future
> though.
>
> Martin Maechler, ETH Zurich
>
>
>>>Can someone confirm the following as a problem:
>>>
>>>R> setClass("Foo", representation(.handle = "externalptr"))
>>>R> object.size(new("Foo"))
>>>Error in object.size(new("Foo")) : object.size: unknown type 22
>>>R> R.version.string
>>>[1] "R version 2.1.1, 2005-06-20"
>>>
>>>R-2.1.1/src/include/Rinternals.h
>>>#define EXTPTRSXP 22/* external pointer */
>>>
>>>R-2.1.1/src/main/size.c:
>>>objectsize(SEXP s) has no case for external pointers
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger D. Peng
http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] object.size() bug?
On 8/5/2005 8:39 AM, Roger D. Peng wrote:
> Would it make sense for 'object.size()' to do the same thing for
> external pointers as it does for environments?
I would think so. For those who haven't looked, this returns the size
of the SEXP for the environment and its attributes, but does not attempt
to work out the size of the contents of the environment. This makes
sense, because environments are references. External pointers are also
references, so their object size should be the size of the pointer
(which is probably 28 bytes; R pointers carry a lot of baggage!), with
no attempt to say anything about the external thing they point to.
Duncan Murdoch
> -roger
>
> Martin Maechler wrote:
>>>"Paul" == Paul Roebuck <[EMAIL PROTECTED]>
>>>on Thu, 4 Aug 2005 00:29:03 -0500 (CDT) writes:
>>
>>
>> Paul> Can someone confirm the following as a problem:
>>
>> Yes, I can. No promiss for a fix in the very near future
>> though.
>>
>> Martin Maechler, ETH Zurich
>>
>>
Can someone confirm the following as a problem:
R> setClass("Foo", representation(.handle = "externalptr"))
R> object.size(new("Foo"))
Error in object.size(new("Foo")) : object.size: unknown type 22
R> R.version.string
[1] "R version 2.1.1, 2005-06-20"
R-2.1.1/src/include/Rinternals.h
#define EXTPTRSXP 22/* external pointer */
R-2.1.1/src/main/size.c:
objectsize(SEXP s) has no case for external pointers
>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 generating function
First, anyone planning to debug methods should consider the general form
of the trace() function with signature= to say what method to trace, and
some suitable interactive function such as "browser" or "recover" to
examine the computations. See ?trace
In this example, something like:
trace("initialize", sig="Superclass", browser)
Now, the specific example. There are 3 special features used:
1. Nonstandard arguments for the initialize method (its official
arguments are (.Object, ...))
2. callNextMethod
3. within callNextMethod, providing explicit arguments. The simple case
is callNextMethod(), which passes on the arguments to the current method.
Turns out that it's the third step that finds a bug in the heuristics
used by callNextMethod to construct the actual call.
In your example, you don't need the explicit arguments since they just
replicate the formal arguments to initialize(). If you omit them, the
computation is simpler & works.
The bug can probably be fixed, but until 2.2 comes out at least, you
need to stick to the simpler callNextMethod().
Removing the extraneous cat() and str() calls, the revised example is:
R> setClass("Superclass", representation(id = "character"),
contains = "VIRTUAL")
[1] "Superclass"
R> setMethod("initialize", signature(.Object = "Superclass"),
function(.Object, id = "") {
if (length(id) > 0) {
[EMAIL PROTECTED] <- i [TRUNCATED]
[1] "initialize"
R> setClass("Subclass", contains = "Superclass")
[1] "Subclass"
R> setMethod("initialize", signature(.Object = "Subclass"),
function(.Object, ...) {
callNextMethod()
})
[1] "initialize"
R> Subclass <- function(id = "") {
new("Subclass", id = id)
}
R> new("Subclass", id = "test1")
An object of class “Subclass”
Slot "id":
[1] "test1"
R> Subclass(id = "test2")
An object of class “Subclass”
Slot "id":
[1] "test2"
---
Paul Roebuck wrote:
> Can someone explain what the problem is when I use the
> generating function? And how to get debug() to stop in
> the Superclass initialize method?
>
>
> source -
> setClass("Superclass",
> representation(id = "character"),
> contains = "VIRTUAL")
>
> setMethod("initialize",
> signature(.Object = "Superclass"),
> function(.Object, id = "") {
> cat("initialize (Superclass)", "\n")
> if (length(id) > 0) {
> cat("\tid =", id, "\n")
> [EMAIL PROTECTED] <- id
> }
> .Object
> })
>
> setClass("Subclass",
> contains = "Superclass")
>
> setMethod("initialize",
> signature(.Object = "Subclass"),
> function(.Object, ...) {
> cat("initialize (Subclass)", "\n")
> cat("\t... =");str(list(...));cat("\n")
> callNextMethod(.Object, ...)
> })
>
> Subclass <- function(id = "") {
> new("Subclass", id = id)
> }
>
> cat("*** Create class using new() ***\n")
> str(new("Subclass", id = "test1"))
>
> cat("*** Create class using generating function ***\n")
> str(Subclass(id = "test2"))
>
>
> output -
> *** Create class using new() ***
> initialize (Subclass)
> ... =List of 1
> $ id: chr "test1"
>
> initialize (Superclass)
> id = test1
> Formal class 'Subclass' [package ".GlobalEnv"] with 1 slots
> ..@ id: chr "test1"
> *** Create class using generating function ***
> initialize (Subclass)
> ... =List of 1
> $ id: chr "test2"
>
> initialize (Superclass)
> Error in .local(.Object, ...) : Object "id" not found
>
>
> Thanks
>
> --
> SIGSIG -- signature too long (core dumped)
>
> __
> 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] object.size() bug?
On Fri, 5 Aug 2005, Duncan Murdoch wrote:
> On 8/5/2005 8:39 AM, Roger D. Peng wrote:
>> Would it make sense for 'object.size()' to do the same thing for
>> external pointers as it does for environments?
>
> I would think so. For those who haven't looked, this returns the size
> of the SEXP for the environment and its attributes, but does not attempt
> to work out the size of the contents of the environment. This makes
> sense, because environments are references. External pointers are also
> references, so their object size should be the size of the pointer
> (which is probably 28 bytes; R pointers carry a lot of baggage!), with
> no attempt to say anything about the external thing they point to.
I think it might also make sense for the code to warn this had been done.
>
> Duncan Murdoch
>
>
>> -roger
>>
>> Martin Maechler wrote:
"Paul" == Paul Roebuck <[EMAIL PROTECTED]>
on Thu, 4 Aug 2005 00:29:03 -0500 (CDT) writes:
>>>
>>>
>>> Paul> Can someone confirm the following as a problem:
>>>
>>> Yes, I can. No promiss for a fix in the very near future
>>> though.
>>>
>>> Martin Maechler, ETH Zurich
>>>
>>>
> Can someone confirm the following as a problem:
>
> R> setClass("Foo", representation(.handle = "externalptr"))
> R> object.size(new("Foo"))
> Error in object.size(new("Foo")) : object.size: unknown type 22
> R> R.version.string
> [1] "R version 2.1.1, 2005-06-20"
>
> R-2.1.1/src/include/Rinternals.h
> #define EXTPTRSXP 22/* external pointer */
>
> R-2.1.1/src/main/size.c:
> objectsize(SEXP s) has no case for external pointers
>>>
>>>
>>> __
>>> 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
>
>
--
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] unable to start pdf, postscript devices (PR#8052)
Full_Name: Jeffrey Freedman Version: 2.1.1 OS: Mac 10.4.2 Submission from: (NULL) (169.226.95.21) All of a sudden, I cannot generate pdf, postscript, jpeg, png graphics. I get the following error: R(273) malloc: *** Deallocation of a pointer not malloced: 0x113e870; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug Error in pdf(psfile) : unable to start device pdf This originally happened running R version 2.1.0. I upgraded to 2.1.1 and the same problem still occurs. No other changes to the operating system and no new software installation has occurred on the computer running R, which is an Apple Dual 2 GHz Power PC G5. Thank you for your attention to this matter. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unable to start pdf, postscript devices (PR#8052)
The following in NEWS is probably relevant: CHANGES IN R VERSION 2.1.1 patched o File creation errors in pdf(), postscript(), xfig() resulted in a pointer being freed twice. (Reported by Matt McCall) So, 1) Please try R-patched as we do ask you to (before sending a bug report). 2) You probably do not have permission to open the files in the current directory, hence the error that is being handled twice. On Fri, 5 Aug 2005 [EMAIL PROTECTED] wrote: > Full_Name: Jeffrey Freedman > Version: 2.1.1 > OS: Mac 10.4.2 > Submission from: (NULL) (169.226.95.21) > > > All of a sudden, I cannot generate pdf, postscript, jpeg, png graphics. I get > the following error: > > R(273) malloc: *** Deallocation of a pointer not malloced: 0x113e870; This > could be a double free(), or free() called with the middle of an allocated > block; Try setting environment variable MallocHelp to see tools to help debug > Error in pdf(psfile) : unable to start device pdf > > This originally happened running R version 2.1.0. I upgraded to 2.1.1 and the > same problem still occurs. No other changes to the operating system and no new > software installation has occurred on the computer running R, which is an > Apple > Dual 2 GHz Power PC G5. > > Thank you for your attention to this matter. > > __ > 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] S4 generating function
On Fri, 5 Aug 2005, John Chambers wrote:
> Paul Roebuck wrote:
>
> > Can someone explain what the problem is when I use the
> > generating function? And how to get debug() to stop in
> > the Superclass initialize method?
> > [SNIP code & output]
>
> Now, the specific example. There are 3 special features used:
> 1. Nonstandard arguments for the initialize method (its official
> arguments are (.Object, ...))
>
> 2. callNextMethod
>
> 3. within callNextMethod, providing explicit arguments. The simple case
> is callNextMethod(), which passes on the arguments to the current method.
>
> Turns out that it's the third step that finds a bug in the heuristics
> used by callNextMethod to construct the actual call.
>
> In your example, you don't need the explicit arguments since they just
> replicate the formal arguments to initialize(). If you omit them, the
> computation is simpler & works.
>
> The bug can probably be fixed, but until 2.2 comes out at least, you
> need to stick to the simpler callNextMethod().
> [SNIP modified code]
Thank you for your help. Unfortunately, this is a case where
posting the simplest code necessary to display the bug works
against the poster. Actual code uses external pointers but
this revision shows more of the general concept.
If I understand your description correctly, the problem is
passing both named and unnamed arguments to callNextMethod().
Can I [easily] do either of these things to avoid the bug?
1) somehow add an argument to 'dots' and invoke callNextMethod()
without arguments?
2) parse 'dots' and invoke callNextMethod() with a completely
named argument list?
-- revised source ---
setClass("Superclass",
representation(.values = "integer",
id = "character"),
contains = "VIRTUAL")
setMethod("initialize",
signature(.Object = "Superclass"),
function(.Object, .values = NULL, id = "") {
cat("initialize (Superclass)", "\n")
if (!is.null(.values)) {
cat("\t.values =", .values, "\n")
[EMAIL PROTECTED] <- .values
}
if (length(id) > 0) {
cat("\tid =", id, "\n")
[EMAIL PROTECTED] <- id
}
.Object
})
setClass("Subclass",
contains = "Superclass")
setMethod("initialize",
signature(.Object = "Subclass"),
function(.Object, count = 1, ...) {
cat("initialize (Subclass)", "\n")
dots <- list(...)
cat("\t... =");str(dots);cat("\n")
.values = integer(count)
callNextMethod(.Object, .values = .values, ...)
})
Subclass <- function(count, id = "") {
new("Subclass", count, id = id)
}
cat("*** Create class using new() ***\n")
str(new("Subclass", id = "test0"))
str(new("Subclass", count = 3, id = "test1"))
cat("*** Create class using generating function ***\n")
#trace("initialize", signature = "Subclass", browser)
str(Subclass(count = 3, id = "test2"))
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 setClass with prototypes " issues" (PR#8053)
To R-Developers:
I wish to report what I believe are inconsistencies between Green Book
descriptions and R methods behaviors. I **realize** that R does not
guarantee total consistency with the Green Book; therefore I leave it to you
to decide whether any of this is a bug, design choice, or a need for
additional documentation -- or whether I have simply misread or overlooked
existing explanations. If the latter, I apologize for the error, but it was
not for a want of effort.
The issues all revolve around the setClass('xxx',prototype=...) without any
slots construction. All references are to the Green Book. R 2.1.1 (on
Windows)
1. Classes so defined (with protype, no slots) are not instantiated as
described on the bottom of p.289. In particular, the following example from
the book fails:
> setClass('sequence',prototype=numeric(3))
[1] "sequence"
> new('sequence',c(1,51,10))
Error in initialize(value, ...) : cannot use object of class "numeric" in
new(): class "sequence" does not extend that class
2. I have been unable to find any Help documentation about the proper method
to instantiate classes defined by prototypes without slots. Experimentation
showed that only one of the two approaches on the bottom of p.289 worked:
> setClass('foo',prototype=numeric())
[1] "foo"
> z<-new('foo')
## new() works as it should
> z
An object of class "foo"
numeric(0)
## But now try this ...
> z<-1:3
> is(z,'numeric')
[1] TRUE
## Hence, if R followed the book's statement that "For this to work,
'object' must either be suitable as a prototype for 'myClass or belong to a
class that can be coerced to 'myClass.'" (Note, I interpret this to mean
that either of these conditions are sufficient for either of the approaches
shown).
> as(z,'foo')
Error in as(z, "foo") : no method or default for coercing "integer" to "foo"
## But
> class(z)<-'foo'
> z
An object of class "foo"
[1] 1 2 3
I was unable to find documentation for this behavior in R, assuming that
this is not a bug. If it's a bug, it should be fixed, of course; if not, I
think the behavior should be documented, perhaps in setClass.
3. Finally, and most disconcertingly, The Green Book says (p.288):
"... We do NOT want a 'sequence' object to be interpreted as a numeric
vector ... Doing arbitrary arithmetic on the object, for example would be
disastrous...
The use of prototypes without representations allows the class designer to
limit the legal computations on objects made up of numeric data..."
As I read this, this should mean that the following should fail, but it
doesn't (continuing the above example):
> z+1
An object of class "foo"
[1] 2 3 4
Again, if this is not a bug, I think that this lack of adherence to the
Green book should be documented in R. May I say, however, that I wish R had
implemented the book's prescription.
-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA
"The business of the statistician is to catalyze the scientific learning
process." - George E. P. Box
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 setClass with prototypes " issues" (PR#8053)
Well, let's say R is currently picky when only a prototype is supplied.
The following is either a workaround or a revised, fussier requirement
for the example mentioned, depending on your interpretation.
R> setClass("sequence", representation(.Data="numeric"),
prototype=numeric(3))
[1] "sequence"
R> xx <- new('sequence',c(1,51,10))
R> xx
An object of class “sequence”
[1] 1 51 10
R> is(xx, "numeric")
[1] FALSE
So far, so good. But there are a couple of catches.
The resolution of prototype and representation is currently somewhat of
a mess in the R implementation. There's been some discussion of
cleaning it up, hopefully moving ahead from the Green Book description
to a more coherent definition. So whether eventually one could (or
should) omit the representation() part remains to be seen.
The other relevant flaw currently is that S4 objects have no special
internal representation in R, so there's effectively no way to keep
primitive operations from working on them. (The general & notorious
example is that xx[] always returns something on an S4 object, even when
it shouldn't.) In the current case, the problem is that, in spite of
not extending "numeric", low-level arithmetic is still done.
R> xx+1
An object of class “sequence”
[1] 2 52 11
Something basic is needed here, in the code for primitives, but so far
objections re efficiency have prevented doing anything.
Meanwhile, those more interested in getting something done than
discussing, would need to implement explicit methods for the new class
that either re-interpret or block the primitives that shouldn't happen
in the standard way.
[EMAIL PROTECTED] wrote:
> To R-Developers:
>
> I wish to report what I believe are inconsistencies between Green Book
> descriptions and R methods behaviors. I **realize** that R does not
> guarantee total consistency with the Green Book; therefore I leave it to you
> to decide whether any of this is a bug, design choice, or a need for
> additional documentation -- or whether I have simply misread or overlooked
> existing explanations. If the latter, I apologize for the error, but it was
> not for a want of effort.
>
> The issues all revolve around the setClass('xxx',prototype=...) without any
> slots construction. All references are to the Green Book. R 2.1.1 (on
> Windows)
>
> 1. Classes so defined (with protype, no slots) are not instantiated as
> described on the bottom of p.289. In particular, the following example from
> the book fails:
>
>
>>setClass('sequence',prototype=numeric(3))
>
> [1] "sequence"
>
>>new('sequence',c(1,51,10))
>
> Error in initialize(value, ...) : cannot use object of class "numeric" in
> new(): class "sequence" does not extend that class
>
> 2. I have been unable to find any Help documentation about the proper method
> to instantiate classes defined by prototypes without slots. Experimentation
> showed that only one of the two approaches on the bottom of p.289 worked:
>
>
>>setClass('foo',prototype=numeric())
>
> [1] "foo"
>
>>z<-new('foo')
>
> ## new() works as it should
>
>>z
>
> An object of class "foo"
> numeric(0)
>
> ## But now try this ...
>
>>z<-1:3
>>is(z,'numeric')
>
> [1] TRUE
> ## Hence, if R followed the book's statement that "For this to work,
> 'object' must either be suitable as a prototype for 'myClass or belong to a
> class that can be coerced to 'myClass.'" (Note, I interpret this to mean
> that either of these conditions are sufficient for either of the approaches
> shown).
>
>
>>as(z,'foo')
>
> Error in as(z, "foo") : no method or default for coercing "integer" to "foo"
>
> ## But
>
>>class(z)<-'foo'
>>z
>
> An object of class "foo"
> [1] 1 2 3
>
> I was unable to find documentation for this behavior in R, assuming that
> this is not a bug. If it's a bug, it should be fixed, of course; if not, I
> think the behavior should be documented, perhaps in setClass.
>
> 3. Finally, and most disconcertingly, The Green Book says (p.288):
>
> "... We do NOT want a 'sequence' object to be interpreted as a numeric
> vector ... Doing arbitrary arithmetic on the object, for example would be
> disastrous...
>
> The use of prototypes without representations allows the class designer to
> limit the legal computations on objects made up of numeric data..."
>
> As I read this, this should mean that the following should fail, but it
> doesn't (continuing the above example):
>
>
>>z+1
>
> An object of class "foo"
> [1] 2 3 4
>
> Again, if this is not a bug, I think that this lack of adherence to the
> Green book should be documented in R. May I say, however, that I wish R had
> implemented the book's prescription.
>
>
> -- Bert Gunter
> Genentech Non-Clinical Statistics
> South San Francisco, CA
>
> "The business of the statistician is to catalyze the scientific learning
> process." - George E. P. Box
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinf
Re: [Rd] S4 generating function
Re:
> If I understand your description correctly, the problem is
> passing both named and unnamed arguments to callNextMethod().
No, as I said the distinction is a potential bug in callNextMethod
_whenever_ it gets explicit arguments. (At the moment, it seems to be a
bug in substitute() or else a different interpretation of that function
from the one in the Blue Book. But I've only looked a little.)
So to work around it you have to be able to do callNextMethod() with no
arguments.
Just at a guess, you may be able to do that if you avoid redefining the
formal arguments for the initialize() method. Leave them as .Object,
... and extract the id= component.
dotArgs <- list(...)
id <- dotArgs$id
Or, wait for a fix. There should at least be one in r-devel sometime
fairly soon.
Paul Roebuck wrote:
> On Fri, 5 Aug 2005, John Chambers wrote:
>
>
>>Paul Roebuck wrote:
>>
>>
>>>Can someone explain what the problem is when I use the
>>>generating function? And how to get debug() to stop in
>>>the Superclass initialize method?
>>>[SNIP code & output]
>>
>>Now, the specific example. There are 3 special features used:
>>1. Nonstandard arguments for the initialize method (its official
>>arguments are (.Object, ...))
>>
>>2. callNextMethod
>>
>>3. within callNextMethod, providing explicit arguments. The simple case
>>is callNextMethod(), which passes on the arguments to the current method.
>>
>>Turns out that it's the third step that finds a bug in the heuristics
>>used by callNextMethod to construct the actual call.
>>
>>In your example, you don't need the explicit arguments since they just
>>replicate the formal arguments to initialize(). If you omit them, the
>>computation is simpler & works.
>>
>>The bug can probably be fixed, but until 2.2 comes out at least, you
>>need to stick to the simpler callNextMethod().
>>[SNIP modified code]
>
>
> Thank you for your help. Unfortunately, this is a case where
> posting the simplest code necessary to display the bug works
> against the poster. Actual code uses external pointers but
> this revision shows more of the general concept.
>
> If I understand your description correctly, the problem is
> passing both named and unnamed arguments to callNextMethod().
> Can I [easily] do either of these things to avoid the bug?
>
> 1) somehow add an argument to 'dots' and invoke callNextMethod()
> without arguments?
> 2) parse 'dots' and invoke callNextMethod() with a completely
> named argument list?
>
>
> -- revised source ---
> setClass("Superclass",
> representation(.values = "integer",
> id = "character"),
> contains = "VIRTUAL")
>
> setMethod("initialize",
> signature(.Object = "Superclass"),
> function(.Object, .values = NULL, id = "") {
> cat("initialize (Superclass)", "\n")
> if (!is.null(.values)) {
> cat("\t.values =", .values, "\n")
> [EMAIL PROTECTED] <- .values
> }
> if (length(id) > 0) {
> cat("\tid =", id, "\n")
> [EMAIL PROTECTED] <- id
> }
> .Object
> })
>
> setClass("Subclass",
> contains = "Superclass")
>
> setMethod("initialize",
> signature(.Object = "Subclass"),
> function(.Object, count = 1, ...) {
> cat("initialize (Subclass)", "\n")
> dots <- list(...)
> cat("\t... =");str(dots);cat("\n")
> .values = integer(count)
> callNextMethod(.Object, .values = .values, ...)
> })
>
> Subclass <- function(count, id = "") {
> new("Subclass", count, id = id)
> }
>
> cat("*** Create class using new() ***\n")
> str(new("Subclass", id = "test0"))
> str(new("Subclass", count = 3, id = "test1"))
>
> cat("*** Create class using generating function ***\n")
> #trace("initialize", signature = "Subclass", browser)
> str(Subclass(count = 3, id = "test2"))
>
> --
> SIGSIG -- signature too long (core dumped)
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] call fortran in R
I am starting to get confused, What should I used to make sure I got the corrected and most recent setup that will allow me to correctly compile and run fortran routine under R.2.1.1 Please note that I am using the last version of MAC OS X, TIGER which is 10.4.2 And that I have presently installed Developer tools (XCODE), 2.2. For your own information what I have presently installed is : Double-G5:~ sebas$ gfortran -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../gcc-4.1-20050611/configure --enable-threads=posix --enable-languages=c++,f95 Thread model: posix gcc version 4.1.0 20050611 (experimental) Double-G5:~ sebas$ gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/configure -- disable-checking --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/ s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.0 (Apple Computer, Inc. build 5026) Double-G5:~ sebas$ g77 -v Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/ specs Configured with: ../gcc/configure --enable-threads=posix --enable- languages=f77 --disable-shared --enable-static Thread model: posix gcc version 3.4.2 Thanks in advance > please don't mix gcc 4.0 and g77. Also don't mix R binary which is > gcc-3.3/g77-3.4.2 with gcc4 or gfortran. > stefano > > On 04/ago/05, at 17:25, Sébastien Durand wrote: > > >> Dear all, >> >> Since the command you ask me to type doesn't show anything >> Here some more information, on my system and on the foo.so >> compiled file >> >> I am using g77 version 3.4.4 Configured with: ../gcc/configure -- >> enable-threads=posix --enable-languages=f77 >> >> I am using gcc version 4.0.0 20041026 (Apple Computer, Inc. build >> 4061) >> Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/ >> configure --disable-checking --prefix=/usr --mandir=/share/man -- >> enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^ >> +.-]*$/s/$/-4.0/ >> --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- >> build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- >> target=powerpc-apple-darwin8 >> >> I don't know if this can be of any help to you but there is again how >> I compile the foo.f >> >> Double-G5:~ sebas$ R CMD SHLIB ~/Desktop/Fortan_kmeans/kmeans3.f >> g77 -fno-common -g -O2 -c /Users/sebas/Desktop/ >> Fortan_kmeans/kmeans3.f -o /Users/sebas/Desktop/Fortan_kmeans/ >> kmeans3.o >> gcc-3.3 -bundle -flat_namespace -undefined suppress -L/usr/ >> local/lib -o /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so /Users/ >> sebas/Desktop/Fortan_kmeans/kmeans3.o -L/usr/local/lib/gcc/powerpc- >> apple-darwin6.8/3.4.2 -lg2c -lSystem -framework R >> >> >> There is all the info about the foo.so file using nm -a option >> instead of -g: >> >> >> Double-G5:~ sebas$ nm -a ~/Desktop/Fortan_kmeans/kmeans3.so >> 0fe4 - 01 0114 SLINE >> 0fb0 - 01 SO >> 0fd8 - 01 010d SLINE >> 0fdc - 01 010e SLINE >> 0fe0 - 01 010f SLINE >> 0fec - 01 0116 SLINE >> 0fe8 - 01 0115 SLINE >> 1000 - 01 SO >> 1000 - 01 011b SLINE >> 0ffc - 01 011a SLINE >> 0ff8 - 01 0119 SLINE >> 0fb4 - 01 0104 SLINE >> 0fb8 - 01 0105 SLINE >> 0fbc - 01 0106 SLINE >> 0fc0 - 01 0107 SLINE >> 0fc4 - 01 0108 SLINE >> 0ff4 - 01 0118 SLINE >> 0fc8 - 01 0109 SLINE >> 0fcc - 01 010a SLINE >> 0fd0 - 01 010b SLINE >> 0fd4 - 01 010c SLINE >> 0ff0 - 01 0117 SLINE >> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57// >> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >> 0fb0 - 01 SO /Users/sebas/ >> 0fb0 - 01 SO /Users/sebas/Desktop/Fortan_kmeans/kmeans3.f >> 0fb0 - 01 SOL >> 0fb0 - 01 SOL >> 0fe0 t __dyld_func_lookup >> 0fe0 - 01 0113 FUN __dyld_func_lookup:F3 >> - 00 LSYM __g77_f2c_address:t(0,10)=*(0,11)[EMAIL PROTECTED];r >> (0,11);-128;127; >> - 00 LSYM __g77_f2c_complex:t(0,7)=R3;8;0; >> - 00 LSYM __g77_f2c_doublecomplex:t(0,6)=R3;16;0; >> - 00 LSYM __g77_f2c_doublereal:t(0,8)=r(0,0);8;0; >> - 00 LSYM __g77_f2c_flag:t(0,3)=r >> (0,3);-2147483648;2147483647; >> - 00 LSYM __g77_f2c_ftnint:t(0,1)=r >> (0,1);-2147483648;2147483647; >> - 00 LSYM __g77_f2c_ftnlen:t(0,2)=r >> (0,2);-2147483648;2147483647; >> - 00 LSYM __g77_f2c_integer:t(0,12)=r >> (0,12);-2147483648;2147483647; >> - 00 LSYM __g77_f2c_logical:t(0,4)=r >> (0,4);-2147483648;2147483647; >> - 00 LSYM __g77_f2c
[Rd] Tests of gcc-4.0.1
I had promised to report on tests of gcc-4.0.1, and have now tracked down all the outstanding issues. I am comparing gcc3 (gcc-3.4.4 including g77) and gcc4 (gcc-4.0.1 including gfortran) on FC3, both i686 and x86_64 (the latter both 64-bit and 32-bit builds). All compiled from the sources (the FC3 update to 3.4.4 was not out when I started this). The bottom line is that 4.0.1 shows none of the serious errors that 4.0.0 showed, but was always slower (usually 4-10% slower) than gcc3 and (see below) about 25 CRAN packages fail only about half of which are attributable to deficiences in the packages. The differences between the outputs has shown some places where R is more sensitive to rounding errors than might have been thought. Amongst these are - ppr (that was known) - lowess, which can be extremely sensitive to the number of iterations allowed, as shown by panel 8 in example(attenu). - contouring, in particular the exact place contour labels are placed. - str, which depended on a test ob == signif(ob, digits.d), and signif() was unnecessarily causing rounding error by dividing by a negative power of 10 (now fixed). - the extreme test in example(smooth.spline), which showed quite large differences. Amongst CRAN packages: RSvgDevice is said to have invalid C acepack, deldir, fMultivar, fOptions, fSeries, frailtypack, gap, gcmrec, hmm.discnp, labdsv, survrec have invalid Fortran. (Most of these have been reported to the maintainers some time ago.) Geneland infinite loops NISTnls, gss, relsurv fail their tests SparseM, asypow, mvtnorm, party, subselect segfault ade4 has an LAPACK error (similar to those seen before) -- 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] call fortran in R
Sebastien, if you want to use the R binary from CRAN, then you should assume gcc 3.3 and g77 3.4.2 (which comes with the installer for this reason). You can force gcc to default to 3.3 using sudo gcc_select 3.3 and sudo gg_select 4.0 to restore the new compiler. If you want to use gcc 4.0 and gfortran, then you need to rebuild ALSO R from sources. If you are developing a package you probably want to build R from r- devel sources (we have recently fixed some configuration issues). I suggest you to read R for Mac OS X FAQ and also http:// wiki.urbanek.info/index.cgi?TigeR stefano On 05/ago/05, at 21:38, Sébastien Durand wrote: > I am starting to get confused, > > What should I used to make sure I got the corrected and most recent > setup that will allow me to correctly compile and run fortran routine > under R.2.1.1 > > Please note that I am using the last version of MAC OS X, TIGER which > is 10.4.2 > > And that I have presently installed Developer tools (XCODE), 2.2. > > > For your own information what I have presently installed is : > > Double-G5:~ sebas$ gfortran -v > Using built-in specs. > Target: powerpc-apple-darwin8.1.0 > Configured with: ../gcc-4.1-20050611/configure --enable-threads=posix > --enable-languages=c++,f95 > Thread model: posix > gcc version 4.1.0 20050611 (experimental) > > Double-G5:~ sebas$ gcc -v > Using built-in specs. > Target: powerpc-apple-darwin8 > Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/configure -- > disable-checking --prefix=/usr --mandir=/share/man --enable- > languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/ > s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- > build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- > target=powerpc-apple-darwin8 > Thread model: posix > > gcc version 4.0.0 (Apple Computer, Inc. build 5026) > Double-G5:~ sebas$ g77 -v > Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/ > specs > Configured with: ../gcc/configure --enable-threads=posix --enable- > languages=f77 --disable-shared --enable-static > Thread model: posix > gcc version 3.4.2 > > Thanks in advance > > > > >> please don't mix gcc 4.0 and g77. Also don't mix R binary which is >> gcc-3.3/g77-3.4.2 with gcc4 or gfortran. >> stefano >> >> On 04/ago/05, at 17:25, Sébastien Durand wrote: >> >> >> >>> Dear all, >>> >>> Since the command you ask me to type doesn't show anything >>> Here some more information, on my system and on the foo.so >>> compiled file >>> >>> I am using g77 version 3.4.4 Configured with: ../gcc/configure -- >>> enable-threads=posix --enable-languages=f77 >>> >>> I am using gcc version 4.0.0 20041026 (Apple Computer, Inc. build >>> 4061) >>> Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/ >>> configure --disable-checking --prefix=/usr --mandir=/share/man -- >>> enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^ >>> [cg][^ >>> +.-]*$/s/$/-4.0/ >>> --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- >>> build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- >>> target=powerpc-apple-darwin8 >>> >>> I don't know if this can be of any help to you but there is again >>> how >>> I compile the foo.f >>> >>> Double-G5:~ sebas$ R CMD SHLIB ~/Desktop/Fortan_kmeans/kmeans3.f >>> g77 -fno-common -g -O2 -c /Users/sebas/Desktop/ >>> Fortan_kmeans/kmeans3.f -o /Users/sebas/Desktop/Fortan_kmeans/ >>> kmeans3.o >>> gcc-3.3 -bundle -flat_namespace -undefined suppress -L/usr/ >>> local/lib -o /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so /Users/ >>> sebas/Desktop/Fortan_kmeans/kmeans3.o -L/usr/local/lib/gcc/powerpc- >>> apple-darwin6.8/3.4.2 -lg2c -lSystem -framework R >>> >>> >>> There is all the info about the foo.so file using nm -a option >>> instead of -g: >>> >>> >>> Double-G5:~ sebas$ nm -a ~/Desktop/Fortan_kmeans/kmeans3.so >>> 0fe4 - 01 0114 SLINE >>> 0fb0 - 01 SO >>> 0fd8 - 01 010d SLINE >>> 0fdc - 01 010e SLINE >>> 0fe0 - 01 010f SLINE >>> 0fec - 01 0116 SLINE >>> 0fe8 - 01 0115 SLINE >>> 1000 - 01 SO >>> 1000 - 01 011b SLINE >>> 0ffc - 01 011a SLINE >>> 0ff8 - 01 0119 SLINE >>> 0fb4 - 01 0104 SLINE >>> 0fb8 - 01 0105 SLINE >>> 0fbc - 01 0106 SLINE >>> 0fc0 - 01 0107 SLINE >>> 0fc4 - 01 0108 SLINE >>> 0ff4 - 01 0118 SLINE >>> 0fc8 - 01 0109 SLINE >>> 0fcc - 01 010a SLINE >>> 0fd0 - 01 010b SLINE >>> 0fd4 - 01 010c SLINE >>> 0ff0 - 01 0117 SLINE >>> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57// >>> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >>> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >>> 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/bundle1.s >>> 0fb0 - 01 SO /Users/sebas/ >>> 0fb0 - 01 SO /Users/sebas/Desktop/Fortan_kmeans/ >>> kmeans3.f >>> 0fb0 - 01 SOL >>> 0fb0 - 01 SOL >>> 0fe0 t __dyld_func_lookup >>> 0fe0 - 01 0
Re: [Rd] call fortran in R
Ok, Thanks a lot for all the info. I will take the time to fix my system, recompile my fortran code and create my package... Sincerely, Sébastien Le 05-08-05 à 17:07, stefano iacus a écrit : > Sebastien, > > if you want to use the R binary from CRAN, then you should assume gcc > 3.3 and g77 3.4.2 (which comes with the installer for this reason). > You can force gcc to default to 3.3 using sudo gcc_select 3.3 > and sudo gg_select 4.0 to restore the new compiler. > > > If you want to use gcc 4.0 and gfortran, then you need to rebuild > ALSO R from sources. > If you are developing a package you probably want to build R from r- > devel sources (we have recently fixed some configuration issues). > > I suggest you to read R for Mac OS X FAQ and also http:// > wiki.urbanek.info/index.cgi?TigeR > > stefano > > > On 05/ago/05, at 21:38, Sébastien Durand wrote: > > >> I am starting to get confused, >> >> What should I used to make sure I got the corrected and most recent >> setup that will allow me to correctly compile and run fortran routine >> under R.2.1.1 >> >> Please note that I am using the last version of MAC OS X, TIGER which >> is 10.4.2 >> >> And that I have presently installed Developer tools (XCODE), 2.2. >> >> >> For your own information what I have presently installed is : >> >> Double-G5:~ sebas$ gfortran -v >> Using built-in specs. >> Target: powerpc-apple-darwin8.1.0 >> Configured with: ../gcc-4.1-20050611/configure --enable-threads=posix >> --enable-languages=c++,f95 >> Thread model: posix >> gcc version 4.1.0 20050611 (experimental) >> >> Double-G5:~ sebas$ gcc -v >> Using built-in specs. >> Target: powerpc-apple-darwin8 >> Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/ >> configure -- >> disable-checking --prefix=/usr --mandir=/share/man --enable- >> languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/ >> s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- >> build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- >> target=powerpc-apple-darwin8 >> Thread model: posix >> >> gcc version 4.0.0 (Apple Computer, Inc. build 5026) >> Double-G5:~ sebas$ g77 -v >> Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin6.8/3.4.2/ >> specs >> Configured with: ../gcc/configure --enable-threads=posix --enable- >> languages=f77 --disable-shared --enable-static >> Thread model: posix >> gcc version 3.4.2 >> >> Thanks in advance >> >> >> >> >> >>> please don't mix gcc 4.0 and g77. Also don't mix R binary which is >>> gcc-3.3/g77-3.4.2 with gcc4 or gfortran. >>> stefano >>> >>> On 04/ago/05, at 17:25, Sébastien Durand wrote: >>> >>> >>> >>> Dear all, Since the command you ask me to type doesn't show anything Here some more information, on my system and on the foo.so compiled file I am using g77 version 3.4.4 Configured with: ../gcc/configure -- enable-threads=posix --enable-languages=f77 I am using gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061) Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/ configure --disable-checking --prefix=/usr --mandir=/share/man -- enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^ [cg][^ +.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- target=powerpc-apple-darwin8 I don't know if this can be of any help to you but there is again how I compile the foo.f Double-G5:~ sebas$ R CMD SHLIB ~/Desktop/Fortan_kmeans/kmeans3.f g77 -fno-common -g -O2 -c /Users/sebas/Desktop/ Fortan_kmeans/kmeans3.f -o /Users/sebas/Desktop/Fortan_kmeans/ kmeans3.o gcc-3.3 -bundle -flat_namespace -undefined suppress -L/ usr/ local/lib -o /Users/sebas/Desktop/Fortan_kmeans/kmeans3.so /Users/ sebas/Desktop/Fortan_kmeans/kmeans3.o -L/usr/local/lib/gcc/ powerpc- apple-darwin6.8/3.4.2 -lg2c -lSystem -framework R There is all the info about the foo.so file using nm -a option instead of -g: Double-G5:~ sebas$ nm -a ~/Desktop/Fortan_kmeans/kmeans3.so 0fe4 - 01 0114 SLINE 0fb0 - 01 SO 0fd8 - 01 010d SLINE 0fdc - 01 010e SLINE 0fe0 - 01 010f SLINE 0fec - 01 0116 SLINE 0fe8 - 01 0115 SLINE 1000 - 01 SO 1000 - 01 011b SLINE 0ffc - 01 011a SLINE 0ff8 - 01 0119 SLINE 0fb4 - 01 0104 SLINE 0fb8 - 01 0105 SLINE 0fbc - 01 0106 SLINE 0fc0 - 01 0107 SLINE 0fc4 - 01 0108 SLINE 0ff4 - 01 0118 SLINE 0fc8 - 01 0109 SLINE 0fcc - 01 010a SLINE 0fd0 - 01 010b SLINE 0fd4 - 01 010c SLINE 0ff0 - 01 0117 SLINE 0fb0 - 01 SOL /SourceCache/Csu/Csu-57// 0fb0 - 01 SOL /SourceCache/Csu/Csu-57/b
Re: [Rd] Tests of gcc-4.0.1
Prof Brian Ripley wrote: >I had promised to report on tests of gcc-4.0.1, and have now tracked down >all the outstanding issues. > >I am comparing gcc3 (gcc-3.4.4 including g77) and gcc4 (gcc-4.0.1 >including gfortran) on FC3, both i686 and x86_64 (the latter both 64-bit >and 32-bit builds). All compiled from the sources (the FC3 update to >3.4.4 was not out when I started this). > >The bottom line is that 4.0.1 shows none of the serious errors that 4.0.0 >showed, but was always slower (usually 4-10% slower) than gcc3 and (see >below) about 25 CRAN packages fail only about half of which are >attributable to deficiences in the packages. > >The differences between the outputs has shown some places where R is more >sensitive to rounding errors than might have been thought. Amongst these >are > >- ppr (that was known) >- lowess, which can be extremely sensitive to the number of iterations > allowed, as shown by panel 8 in example(attenu). >- contouring, in particular the exact place contour labels are placed. >- str, which depended on a test ob == signif(ob, digits.d), and signif() > was unnecessarily causing rounding error by dividing by a negative power > of 10 (now fixed). >- the extreme test in example(smooth.spline), which showed quite large > differences. > >Amongst CRAN packages: > >RSvgDevice is said to have invalid C > >acepack, deldir, fMultivar, fOptions, fSeries, frailtypack, gap, gcmrec, >hmm.discnp, labdsv, survrec > >have invalid Fortran. (Most of these have been reported to the maintainers >some time ago.) > >Geneland infinite loops >NISTnls, gss, relsurv fail their tests >SparseM, asypow, > The fortran left in asypow does things (noncentral chisquare distribution) which are available at the R level. If problem if with the fortran I remove it completely. Kjetil > mvtnorm, party, subselect segfault >ade4 has an LAPACK error (similar to those seen before) > > > -- Kjetil Halvorsen. Peace is the most effective weapon of mass construction. -- Mahdi Elmandjra -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
