Re: [Rd] Building an R GUI using gWidgets and RGtk2

2007-09-14 Thread Gabor Grothendieck
On 9/14/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Gerlanc, Daniel <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I'm developing a GUI in R that will be used to monitor financial
> > portfolio performance.  The GUI will be distributed as an R package.  So
> > far, I've decided to use the "cairoDevice", "RGtk2", "gWidgets", and
> > "gWidgetsRGtk2" packages to develop the GUI.  I am trying to decide what
> > would be the best way to structure the GUI would be.
> >
> > I've considered 3 approaches to building the GUI.  The first would be to
> > use S4 classes.  I would create parent "gui" object that would store
> > widgets or containers in slots.  Other more specialized guis for
> > different purposes would extend this parent "gui" object.  The
> > difficulty in this approach is R's use of pass-by-value.  Once the gui
> > object has been created, changing any of the slots of the gui requires
> > returning a new GUI object or saving one off in a higher level
> > environment and editing the slots directly.  Editing the slots directly
> > would completely bypass the S4 method dispatch.
> >
> > Another approach would be more functional.  I would create variables
> > that are global within the package or in their own environment and
> > define the package function closures within this environment.  This
> > could work, but the code could get noisy when calls to have be made to
> > distinguish between local variable assignment within the environment of
> > the functions and assignment within the namespace of the package.
> >
> > The third approach I've been considering is using the R.oo package.  I
> > have never used this package before but it appears to provide similar OO
> > features to Java.  Because it allows references, it would seem to
> > provide the features I'm looking for from both the S4 and functional
> > approaches.
> >
> > Any comments or suggestions on these different approaches would be
> > appreciated.
> >
> > Thank you.
> >
> > Sincerely,
> >
> > Daniel Gerlanc
> A fourth approach would be the proto package.  It provides a thin
> layer over environments making use of the prototype (aka object-based)
> style of programming which is fundamental different relative to
> class-based programming (although it is powerful enough to encompass
> class based programming).  The gsubfn package uses proto objects
> as generalizations of replacement strings that hold state from one replacement
> to the next.  An application that may be closer to yours that uses proto
> is ggplot2 which is a recent grid-based plotting package.  The home page is at
>   http://r-proto.googlecode.com .
> See the paper on prototype programming linked on the home page as well
> as the package vignette.

Just to illustrate this further here is a simple example of gWidgets and
proto.  In this example we create a proto object, p, that corresponds to
an ok/cancel dialogue labelled Hello and that prints Hello when OK is
pressed.  The components of p are go, msg and handler.  msg is
a character string, go is a method and handler is a function (to be
a method it would have to pass the proto object as its first arg).

q is created as a child of p so q gets components via
delegation from p.  q overrides msg which was "Hello" in p but is "Bye"
in q.  q acts the same as p except the label is Bye and q prints Bye when
OK is pressed.  Note that we pass the proto object to the handler via
the action= argument.  Here we used a dot (.) to denote the current
object but you could use this or self or any variable name you prefer.

library(proto)
library(gWidgets)
p <- proto(go = function(.) {
w = gwindow()
g = ggroup(container = w)
g.i = ggroup(horizontal=FALSE, container = g)
glabel(.$msg, container = g.i, expand = TRUE)
g.i.b = ggroup(container = g.i)
addSpring(g.i.b)
gbutton("ok", handler = with(., handler), action = ., container = g.i.b)
gbutton("cancel", handler = function(h, ...) dispose(w),
container = g.i.b)
},
msg = "Hello",
handler = function(h, ...) {
cat("\n", h$action$msg, "\n")
dispose(h$obj)
}
)
p$go()  # press ok and Hello is printed

q <- p$proto(msg = "Bye") # q is child of p overriding msg
q$go()  # press ok and Bye is printed

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


Re: [Rd] Date vs date

2007-09-14 Thread Gabor Grothendieck
On 9/14/07, Terry Therneau <[EMAIL PROTECTED]> wrote:
>  I wrote the date package long ago, and it has been useful.  In my current 
> task
> of reunifying the R (Tom Lumley) and Splus (me) code trees for survival, I'm
> removing the explicit dependence on 'date' objects from the expected survival
> routines so that they better integrate.   Comparison of 'date' to 'Date' has
> raised a couple of questions.
>
>  Clearly Date is more mature -- more options for conversion, better plotting,
> etc (a long list of etc).  I see three things where date is better.  Only the
> last of these really matters, and is the point on which I would like comment.
> (Well, actually I'd like to talk you all into a change, of course).
>
>  1. Since date uses 1/1/1960 as the base, and so does SAS, those of us who
> contantly pass files back and forth between those two packages have a slightly
> easier time.

There are some other programs that use 1/1/70.  See the R Help Desk article
in R News 4/1 that discusses a few origins.

>
>  2. as.date(10) works, as.Date(10) does not.  Sometimes I have done a
> manipluation that the date package does not understand, and I know that the
> result is still of the right type, but the package does not.  However, this is
> fairly rare and I can work around it. (It mostly occurs in processing the rate
> tables for expected survival).

You can define as.Date.numeric in your package and then it will work.  zoo
has done that.

library(zoo)
as.Date(10)

Some other things you can do:

today <- Sys.Date()
Epoch <- today - as.numeric(today)

Epoch + 10  # similar to as.Date(10)

>
>  3. temp <- as.Date('1990/1/1') - as.date('1953/2/5')
> sqrt(temp)
> Error in Math.difftime(temp3) : sqrtnot defined for "difftime" objects
>
>  Minor bug: no space before the word 'not'
>  Major: this shouldn't fail.
>
> People will do things with time intervals that you have not thought of.  
> Fitting
> a growth curve that uses a square root, for instance.  I firmly believe that 
> the
> superior behavior in the face of something unexpected is to assume that the 
> user
> knows what they are doing, and return a numeric.
>   I recognize that "assume the user knows what they are doing" is an anathema
> to the more zealous OO types, but in designing a class I have found that they
> often know more than me!
>
>   4. Variation on #3 above
>
> > (as.Date('2007-9-14') - as.Date('1953-3-10')) / 365.25
>  Time difference of 54.51335 days
>
>No, I am not 54.5 days old.  Both hair color and knee creaking most
> definitely proclaim otherwise, I am sorry to say. Time difference / number
> should be a number.

Note that you can write:

x <- Sys.Date()
y <- x + 1
as.numeric(x-y)
as.numeric(x) - as.numeric(y)

>
>   5. This is only amusing.  Im not saying that as.Date should necessarily 
> work,
> but the format is certainly not ambiguous.  (Not standard, but not ambiguous).
> Not important to fix, not something that date does any better.
>
> > as.Date('09Sep2007')
> Error in fromchar(x) : character string is not in a standard unambiguous 
> format

as.Date("09Sep2007", "%d%b%Y")

>
>
>
>Terry Therneau

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


Re: [Rd] Building an R GUI using gWidgets and RGtk2

2007-09-14 Thread Gabor Grothendieck
A fourth approach would be the proto package.  It provides a thin
layer over environments making use of the prototype (aka object-based)
style of programming which is fundamental different relative to
class-based programming (although it is powerful enough to encompass
class based programming).  The gsubfn package uses proto objects
as generalizations of replacement strings that hold state from one replacement
to the next.  An application that may be closer to yours that uses proto
is ggplot2 which is a recent grid-based plotting package.  The home page is at
   http://r-proto.googlecode.com .
See the paper on prototype programming linked on the home page as well
as the package vignette.

On 9/14/07, Gerlanc, Daniel <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm developing a GUI in R that will be used to monitor financial
> portfolio performance.  The GUI will be distributed as an R package.  So
> far, I've decided to use the "cairoDevice", "RGtk2", "gWidgets", and
> "gWidgetsRGtk2" packages to develop the GUI.  I am trying to decide what
> would be the best way to structure the GUI would be.
>
> I've considered 3 approaches to building the GUI.  The first would be to
> use S4 classes.  I would create parent "gui" object that would store
> widgets or containers in slots.  Other more specialized guis for
> different purposes would extend this parent "gui" object.  The
> difficulty in this approach is R's use of pass-by-value.  Once the gui
> object has been created, changing any of the slots of the gui requires
> returning a new GUI object or saving one off in a higher level
> environment and editing the slots directly.  Editing the slots directly
> would completely bypass the S4 method dispatch.
>
> Another approach would be more functional.  I would create variables
> that are global within the package or in their own environment and
> define the package function closures within this environment.  This
> could work, but the code could get noisy when calls to have be made to
> distinguish between local variable assignment within the environment of
> the functions and assignment within the namespace of the package.
>
> The third approach I've been considering is using the R.oo package.  I
> have never used this package before but it appears to provide similar OO
> features to Java.  Because it allows references, it would seem to
> provide the features I'm looking for from both the S4 and functional
> approaches.
>
> Any comments or suggestions on these different approaches would be
> appreciated.
>
> Thank you.
>
> Sincerely,
>
> Daniel Gerlanc
>
> __
> 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


[Rd] Incomplete library linking for grDevices.so on Solaris (PR#9910)

2007-09-14 Thread gordonp
Full_Name: Paul Gordon
Version: 2.6.1 (alpha)
OS: Solaris 10
Submission from: (NULL) (136.159.169.6)


When compiling R 2.6.1 (alpha 2007-09-13), grDevices.so fails to link properly
because of a missing symbol __vlog_.  This symbol is defined in libmvec.so, but
no -lmvec is add by the configure script.  Manually adding -lmvec to the linking
command allows grDevices to compile.  The error output of the make command (for
a 64-bit version of R) is given below:

cc -G -m64 -L/lib/64 -L/usr/lib/64 -L/usr/local/lib/64 -L/usr/ucblib/sparcv9
-L/usr/ccs/lib/sparcv9 -L/opt/SUNWspro/prod/lib/sparcv9 -o grDevices.so chull.o
devNull.o devPicTeX.o devPS.o devQuartz.o init.o
Warning in solve.default(rgb) :
  unable to load shared library
'/export/home/gordonp/Desktop/R-alpha/modules//lapack.so':
  ld.so.1: R: fatal: relocation error: file
/export/home/gordonp/Desktop/R-alpha/lib/libRlapack.so: symbol __vlog_:
referenced symbol not found
Error in solve.default(rgb) : lapack routines cannot be loaded
Error: unable to load R code in package 'grDevices'

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


Re: [Rd] Date vs date

2007-09-14 Thread hadley wickham
> >   3. temp <- as.Date('1990/1/1') - as.date('1953/2/5')
> >  sqrt(temp)
> >  Error in Math.difftime(temp3) : sqrtnot defined for "difftime" objects
> >
> >   Minor bug: no space before the word 'not'
> >   Major: this shouldn't fail.
> >
> >
> Arguably, it should (Is this a difftime object? Which units?).
> I'd advise against numeric operation on difftime objects in general,
> because of the unspecified units. These are always "days" when working
> with Date objects, but with general time objects it is not predictable.
> So I'd recommend sqrt(as.numeric(temp, units="days")).

Why not just always use seconds for difftime objects?  An attribute
could control how it was formatted, but would be independent of the
underlying representation.

Hadley

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


Re: [Rd] Date vs date

2007-09-14 Thread Peter Dalgaard
Terry Therneau wrote:
>  I wrote the date package long ago, and it has been useful.  In my current 
> task 
> of reunifying the R (Tom Lumley) and Splus (me) code trees for survival, I'm 
> removing the explicit dependence on 'date' objects from the expected survival 
> routines so that they better integrate.   Comparison of 'date' to 'Date' has 
> raised a couple of questions.
>  
>   Clearly Date is more mature -- more options for conversion, better 
> plotting, 
> etc (a long list of etc).  I see three things where date is better.  Only the 
> last of these really matters, and is the point on which I would like comment. 
>  
> (Well, actually I'd like to talk you all into a change, of course).
>   
>   1. Since date uses 1/1/1960 as the base, and so does SAS, those of us who 
> contantly pass files back and forth between those two packages have a 
> slightly 
> easier time.
>
>   2. as.date(10) works, as.Date(10) does not.  Sometimes I have done a 
> manipluation that the date package does not understand, and I know that the 
> result is still of the right type, but the package does not.  However, this 
> is 
> fairly rare and I can work around it. (It mostly occurs in processing the 
> rate 
> tables for expected survival).
>   
The ideology here is that the origin is an implementation detail which 
users are not really expected to know. as.Date("1960-1-1")+10  works, 
and if you insist, so does structure(10, class="Date") (albeit not with 
the same result).

>   
>   3. temp <- as.Date('1990/1/1') - as.date('1953/2/5')
>  sqrt(temp)
>  Error in Math.difftime(temp3) : sqrtnot defined for "difftime" objects
>
>   Minor bug: no space before the word 'not'
>   Major: this shouldn't fail.  
>
>   
Arguably, it should (Is this a difftime object? Which units?).
I'd advise against numeric operation on difftime objects in general, 
because of the unspecified units. These are always "days" when working 
with Date objects, but with general time objects it is not predictable. 
So I'd recommend sqrt(as.numeric(temp, units="days")).

> People will do things with time intervals that you have not thought of.  
> Fitting 
> a growth curve that uses a square root, for instance.  I firmly believe that 
> the 
> superior behavior in the face of something unexpected is to assume that the 
> user 
> knows what they are doing, and return a numeric.  
>I recognize that "assume the user knows what they are doing" is an 
> anathema 
> to the more zealous OO types, but in designing a class I have found that they 
> often know more than me!
>
>4. Variation on #3 above
>
>   
>> (as.Date('2007-9-14') - as.Date('1953-3-10')) / 365.25
>> 
>   Time difference of 54.51335 days
>
> No, I am not 54.5 days old.  Both hair color and knee creaking most 
> definitely proclaim otherwise, I am sorry to say. Time difference / number 
> should be a number.  
>   
Same story as above. It is assumed that the divisor is unit-less. 
Convert to numeric first to avoid this. (The idea has been raised to 
introduce new units: epiyears and epimonths, in which case you might do

x <- as.Date('2007-9-14') - as.Date('1953-3-10')
units(x) <- "epiyears"

which would give you the age in years for those purposes where you don't 
care missing the exact birthday by a day or so.)
> 
>5. This is only amusing.  Im not saying that as.Date should necessarily 
> work, 
> but the format is certainly not ambiguous.  (Not standard, but not ambiguous).
> Not important to fix, not something that date does any better.
>
>   
>> as.Date('09Sep2007')
>> 
> Error in fromchar(x) : character string is not in a standard unambiguous 
> format
>  
>
>   
Yes. Also: this _is_ ambiguous, but does not cause an error

 > as.Date("05-06-07")
[1] "5-06-07"

Not that it should or even could, but it demonstrates that the error 
message above is beside the point.  Can you suggest a better wording?
 


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

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


[Rd] Building an R GUI using gWidgets and RGtk2

2007-09-14 Thread Gerlanc, Daniel
Hello,

I'm developing a GUI in R that will be used to monitor financial
portfolio performance.  The GUI will be distributed as an R package.  So
far, I've decided to use the "cairoDevice", "RGtk2", "gWidgets", and
"gWidgetsRGtk2" packages to develop the GUI.  I am trying to decide what
would be the best way to structure the GUI would be.

I've considered 3 approaches to building the GUI.  The first would be to
use S4 classes.  I would create parent "gui" object that would store
widgets or containers in slots.  Other more specialized guis for
different purposes would extend this parent "gui" object.  The
difficulty in this approach is R's use of pass-by-value.  Once the gui
object has been created, changing any of the slots of the gui requires
returning a new GUI object or saving one off in a higher level
environment and editing the slots directly.  Editing the slots directly
would completely bypass the S4 method dispatch.

Another approach would be more functional.  I would create variables
that are global within the package or in their own environment and
define the package function closures within this environment.  This
could work, but the code could get noisy when calls to have be made to
distinguish between local variable assignment within the environment of
the functions and assignment within the namespace of the package.

The third approach I've been considering is using the R.oo package.  I
have never used this package before but it appears to provide similar OO
features to Java.  Because it allows references, it would seem to
provide the features I'm looking for from both the S4 and functional
approaches.

Any comments or suggestions on these different approaches would be
appreciated.

Thank you.

Sincerely,

Daniel Gerlanc

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


[Rd] Date vs date

2007-09-14 Thread Terry Therneau
 I wrote the date package long ago, and it has been useful.  In my current task 
of reunifying the R (Tom Lumley) and Splus (me) code trees for survival, I'm 
removing the explicit dependence on 'date' objects from the expected survival 
routines so that they better integrate.   Comparison of 'date' to 'Date' has 
raised a couple of questions.
 
  Clearly Date is more mature -- more options for conversion, better plotting, 
etc (a long list of etc).  I see three things where date is better.  Only the 
last of these really matters, and is the point on which I would like comment.  
(Well, actually I'd like to talk you all into a change, of course).
  
  1. Since date uses 1/1/1960 as the base, and so does SAS, those of us who 
contantly pass files back and forth between those two packages have a slightly 
easier time.

  2. as.date(10) works, as.Date(10) does not.  Sometimes I have done a 
manipluation that the date package does not understand, and I know that the 
result is still of the right type, but the package does not.  However, this is 
fairly rare and I can work around it. (It mostly occurs in processing the rate 
tables for expected survival).
  
  3. temp <- as.Date('1990/1/1') - as.date('1953/2/5')
 sqrt(temp)
 Error in Math.difftime(temp3) : sqrtnot defined for "difftime" objects

  Minor bug: no space before the word 'not'
  Major: this shouldn't fail.  

People will do things with time intervals that you have not thought of.  
Fitting 
a growth curve that uses a square root, for instance.  I firmly believe that 
the 
superior behavior in the face of something unexpected is to assume that the 
user 
knows what they are doing, and return a numeric.  
   I recognize that "assume the user knows what they are doing" is an anathema 
to the more zealous OO types, but in designing a class I have found that they 
often know more than me!
   
   4. Variation on #3 above
   
> (as.Date('2007-9-14') - as.Date('1953-3-10')) / 365.25
  Time difference of 54.51335 days
   
No, I am not 54.5 days old.  Both hair color and knee creaking most 
definitely proclaim otherwise, I am sorry to say. Time difference / number 
should be a number.  

   5. This is only amusing.  Im not saying that as.Date should necessarily 
work, 
but the format is certainly not ambiguous.  (Not standard, but not ambiguous).
Not important to fix, not something that date does any better.

> as.Date('09Sep2007')
Error in fromchar(x) : character string is not in a standard unambiguous format
 


Terry Therneau

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


Re: [Rd] problems for ./configure on Ralpha: gcc related

2007-09-14 Thread Stéphane Dray
Thanks Simon,

My gcc seemed to work... but I found the problem: I have to install 
libc6-dev and after I have to install g++
Now it works, I have make R without problems.

Cheers,


Simon Urbanek wrote:
> Stéphane,
>
> the problem is that your compiler doesn't work (as the message clearly 
> tells you). You must have working compiler (and other development 
> tools) before you try compiling R.
>
> I have no clue how you managed to get such a broken compiler, because 
> Debian comes with a complete, working compiler suite ... you should 
> fix your OS in the first place ...
>
> BTW according to Google Ralpha is a "Russian American Space 
> Cooperation", so I wonder how you got it on your computer in the first 
> place ;)
>
> Cheers,
> Simon
>
>
> On Sep 14, 2007, at 10:27 AM, Stéphane Dray wrote:
>
>> Dear all,
>> I am trying to compile Ralpha on my computer (OS = Debian). SVN 
>> Revision is:
>>
>> Revision: 42843
>> Last Changed Date: 2007-09-14
>>
>> ./configure returns :
>> 
>> [EMAIL PROTECTED]:~/Rdev/R-alpha$ ./configure
>> checking build system type... i686-pc-linux-gnulibc1
>> checking host system type... i686-pc-linux-gnulibc1
>> loading site script './config.site'
>> loading build specific script './config.site'
>> checking for pwd... /bin/pwd
>> checking whether builddir is srcdir... yes
>> checking for working aclocal... found
>> checking for working autoconf... found
>> checking for working automake... found
>> checking for working autoheader... found
>> checking for gawk... gawk
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking whether ln -s works... yes
>> checking for ranlib... ranlib
>> checking for bison... bison -y
>> checking for ar... ar
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking for sed... /bin/sed
>> checking for less... /usr/bin/less
>> checking for perl... /usr/bin/perl
>> checking whether perl version is at least 5.8.0... yes
>> checking for dvips... /usr/bin/dvips
>> checking for tex... /usr/bin/tex
>> checking for latex... /usr/bin/latex
>> checking for makeindex... /usr/bin/makeindex
>> checking for pdftex... /usr/bin/pdftex
>> checking for pdflatex... /usr/bin/pdflatex
>> checking for makeinfo... /usr/bin/makeinfo
>> checking whether makeinfo version is at least 4.7... yes
>> checking for texi2dvi... /usr/bin/texi2dvi
>> checking for unzip... /usr/bin/unzip
>> checking for zip... /usr/bin/zip
>> checking for gzip... /bin/gzip
>> checking for firefox... /usr/bin/firefox
>> using default browser ... /usr/bin/firefox
>> checking for acroread... /usr/bin/acroread
>> checking for gcc... gcc
>> checking for C compiler default output file name... configure: error: C
>> compiler cannot create executables
>> See `config.log' for more details.
>> 
>> gcc  -v returns
>> Using built-in specs.
>> Target: i486-linux-gnu
>> Configured with: ../src/configure -v
>> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
>> --enable-shared --with-system-zlib --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
>> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
>> --enable-targets=all --disable-werror --enable-checking=release
>> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
>> Thread model: posix
>> gcc version 4.2.1 (Debian 4.2.1-3)
>>
>> and in the config.log, I have:
>> .
>> configure:4596: checking for gcc
>> configure:4612: found /usr/bin/gcc
>> configure:4623: result: gcc
>> configure:4861: checking for C compiler version
>> configure:4868: gcc --version >&5
>> gcc (GCC) 4.2.1 (Debian 4.2.1-3)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There 
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>
>> configure:4871: $? = 0
>> configure:4878: gcc -v >&5
>> Using built-in specs.
>> Target: i486-linux-gnu
>> Configured with: ../src/configure -v
>> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
>> --enable-shared --with-system-zlib --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --enable-nls
>> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
>> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
>> --enable-targets=all --disable-werror --enable-checking=release
>> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
>> Thread model: posix
>> gcc version 4.2.1 (Debian 4.2.1-3)
>> configure:4881: $? = 0
>> configure:4888: gcc -V >&5
>> gcc: '-V' option must have argument
>> configure:4891: $? = 1
>> configure:4914: checking for C compiler default output file name
>> configure:4941: gcc  -I/usr/local/include -L/usr/local/lib 

Re: [Rd] problems for ./configure on Ralpha: gcc related

2007-09-14 Thread Hin-Tak Leung
Stéphane Dray wrote:
> Dear all,
> I am trying to compile Ralpha on my computer (OS = Debian). SVN Revision is:
> 
> Revision: 42843
> Last Changed Date: 2007-09-14
> 
> ./configure returns :


> checking for C compiler default output file name... configure: error: C 
> compiler cannot create executables
> See `config.log' for more details.


> configure:4941: gcc  -I/usr/local/include -L/usr/local/lib conftest.c  >&5
> /usr/bin/ld: crt1.o: No such file: No such file or directory
> collect2: ld returned 1 exit status


The error message is as it says - crt1.o not found. It is located in 
/usr/lib/ or /usr/lib64 usually, and is part of the glibc-devel package
on redhat or rpm based systems, and probably has a similiar name on
Debian (although they have a funny way of mincing and separating 
packages into sub-packages unnecessarily, but I digress...).

My suggestion would be to apt-get any debian packages which says 
glibc-*, particularly glibc-*-dev-* .

HTL

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


Re: [Rd] Reciprocal Mill's Ratio

2007-09-14 Thread Charles C. Berry

On Fri, 14 Sep 2007, [EMAIL PROTECTED] wrote:


I believe that this may be more appropriate here in r-devel than in r-help.

The normal hazard function, or reciprocal Mill's Ratio, may be obtained
in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for
small values of z. The latter formula breaks dowm numerically for me
(running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4
or greater.



OK,


mr <- function(z )dnorm( z )/ ( pnorm(z,lower=FALSE) )
mr.2 <- function(z) exp(dnorm( z, log=TRUE ) - (pnorm(z, lower=FALSE, log=TRUE 
)))

mr(seq(10,100,by=10)) # breaks before 40

 [1] 10.09809 20.04975 30.03326  NaN  NaN  NaN  NaN  NaN
  NaN  NaN


mr.2(seq(10,100,by=10)) #seems robust

 [1]  10.09809  20.04975  30.03326  40.02497  50.01998  60.01666  70.01428  
80.01250  90.0 100.01000



mr.2(1e4)

[1] 1

mr.2(1e5)

[1] 9.97

mr.2(1e6)

[1] 80.2

mr.2(1e7)

[1] 9990923

mr.2(1e8) # Oh well!

[1] 65659969




I guess you get large than 1e4, you should just use the asymptotic result.

HTH,

Chuck




Looking at the pnorm documentation I see that it is based on Cody (1993)
and thence, going one step further back, on Cody (1969). Consulting
Cody (1969) I see that the algorithm for pnorm(z) [or actually erf(z)]
is actually based on rational function approximations for the
reciprocal Mill's ratio itself, as I rather expected.

I wonder if anyone has dug out a function for the reciprocal Mill's
ratio out of the pnorm() code? Anticipating the obvious response I don't
believe that this would be one of the things I might be good at!

Murray Jorgensen

References

Cody, W. D. (1993)
Algorithm 715: SPECFUN – A portable FORTRAN package of special function
routines and test drivers.
ACM Transactions on Mathematical Software 19, 22–32.

Cody, W. D. (1969)
Rational Chebyshev Approximations for the Error Function
Mathematics of Computation, Vol. 23, No. 107. (Jul., 1969), pp. 631-637.

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



Charles C. Berry(858) 534-2098
Dept of Family/Preventive Medicine
E mailto:[EMAIL PROTECTED]  UC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901

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


Re: [Rd] partial correlation function for multivariate time series

2007-09-14 Thread Simone Giannerini
Dear Paul,

thanks for the reply,

On 14/09/2007, Paul Gilbert <[EMAIL PROTECTED]> wrote:
>
> Simone Giannerini wrote:
> > Dear Paul,
> >
> > there is no mention to the pacf in the multivariate setting in the book
> > you suggested.
>
> My apologies, I should have looked more carefully and realized the pacf
> discussion in Granger and Newbold is all univariate.
>
> > As I mentioned in private I suspect that pacf() in the multivariate case
> > computes the
> > partial autoregression matrix (in the terminology of Reinsel) rather
> > than the partial autocorrelation matrix
>
> It looks like pacf() uses the calculation in stats:::ar.yw.default , so
> roughly sounds consistent with what you say. I do think parts of this
> code pre-date Reisel's book, so inconsistency with his book would
> probably be imperfect foresight.
>
> BTW, I think bug reports with suggested fixes are usually more useful.
> And, at the very least, it seems the references in the documentation
> could be improved.


Yes, my intention is to have a look at a way to fix the problem once the
problem has been recognized as such.
I did not have a look at the source code yet but if it is C I am afraid I
won't be able to go very far as I use fortran instead.

Regards,

Simone


Paul Gilbert
>
> > as the two coincide in the univariate case but are different in the
> > multivariate case as stated explicitly
> > in Reisel (Sec. 3.3).
> > This would explain the coefficients well above 1 (in modulus) in the
> > example I have given.
> > To support my statement you can fit A VAR model to the data and compare
> > the coefficients with the results
> > from pacf():
> >
> > set.seed(10)
> > x <- rnorm(1000,sd=1)
> > y <- rnorm(1000,sd=1)
> >
> > library(vars);
> > mod1 <- VAR(ts(cbind(x,y)),p=4,type="none"); # fit a VAR (OLS)
> >
> > ## Have a look at estimated coefficients
> >
> >>  noquote(formatC(mod1$varresult$x$coefficients,format="f"))
> > ## Edited by me, compare with the first column of the results below from
> > the pacf (pacf()$acf[,1,])
> >  x.l1 x.l2x.l3x.l4
> >  0.0470.013   0.004   0.014
> >  y.l1 y.l2y.l3y.l4
> >  374.117  72.758 -526.452 126.610
> >>  noquote(formatC(mod1$varresult$y$coefficients,format="f"))
> > ## Edited by me, compare with the second column of the results below
> > from the pacf (pacf()$acf[,2,])
> >  x.l1x.l2 x.l3x.l4
> >  0.000   -0.000   0.000   0.000
> >  y.l1y.l2 y.l3y.l4
> > -0.046   -0.025  -0.033  -0.020
> >
> > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=4)
> >
> > Partial autocorrelations of series 'ts(cbind(x, y))', by lag
> >
> > , , x
> >
> >  x y
> > 0.047 ( 1)0.000 (-1)
> > 0.011 ( 2)0.000 (-2)
> > 0.005 ( 3)0.000 (-3)
> > 0.013 ( 4)0.000 (-4)
> >
> > , , y
> >
> >  x y
> >   374.052 ( 1)   -0.045 ( 1)
> >66.717 ( 2)   -0.024 ( 2)
> >  -535.810 ( 3)   -0.031 ( 3)
> >   120.802 ( 4)   -0.020 ( 4)
> >
> > As you can see the coefficients fairly agree.
> > I might file a bug report in some days unless someone will prove me
> > wrong before.
> >
> > Regards,
> >
> > Simone
> >
> >
> >
> > On 11/09/2007, *Paul Gilbert* <[EMAIL PROTECTED]
> > > wrote:
> >
> > I think the reference for pacf is
> >
> > @BOOK{GraNew77,
> >author ={Granger, C. W. J. and Newbold, Paul},
> >title = {Forecasting Economic Time Series},
> >publisher = {Academic Press},
> >year =  1977
> >}
> >
> > It certainly would not be Reisel's book, as parts of the code
> predate
> > that by many years.
> >
> > Paul Gilbert
> >
> > Simone Giannerini wrote:
> >  > Dear all,
> >  >
> >  > I found the following behaviour with pacf() in the multivariate
> > case,
> >  >
> >  > set.seed(10)
> >  > x <- rnorm(1000,sd=1)
> >  > y <- rnorm(1000,sd=1)
> >  > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10)
> >  >
> >  > Partial autocorrelations of series 'cbind(x, y)', by lag
> >  >
> >  > , , x
> >  >
> >  >  x  y
> >  > 0.047 (  1)0.000 ( -1)
> >  > 0.011 (  2)0.000 ( -2)
> >  > 0.005 (  3)0.000 ( -3)
> >  > 0.013 (  4)0.000 ( -4)
> >  > 0.050 (  5)0.000 ( -5)
> >  > 0.034 (  6)0.000 ( -6)
> >  > 0.026 (  7)0.000 ( -7)
> >  >-0.029 (  8)0.000 ( -8)
> >  >-0.010 (  9)0.000 ( -9)
> >  >-0.013 ( 10)0.000 (-10)
> >  >
> >  > , , y
> >  >
> >  >  x  y
> >  >   374.052 (  1)   -0.045 (  1)
> >  >66.717 (  2)   -0.024 (  2)
> >  >  -535.810 (  3)   -0.031 (  3)
> >  >   120.802 (  4)   -0.020 (  4)
> >  >   142.824 (  5)0.004 (  5)
> >  >  -211.711 (  6)   -0.010 (  6)
> >  >   201.856 (  7)0.058 (  7)
> >  >   286.079 (  8)   -0.035 (  8)
> >  >  -134.057 

Re: [Rd] problems for ./configure on Ralpha: gcc related

2007-09-14 Thread Dirk Eddelbuettel

Salut Stéphane, 

On 14 September 2007 at 16:27, Stéphane Dray wrote:
| Dear all,
| I am trying to compile Ralpha on my computer (OS = Debian). SVN Revision is:
| 
| Revision: 42843
| Last Changed Date: 2007-09-14

Revision 2007-09-10 without a hitch and is in Debian unstable, see

http://buildd.debian.org/build.php?pkg=r-base

for the build logs (and my embarassing three revisions to get r-cran.mk [ for
r-cran-* packages ] right).

So if I were you I'd start with (assuming you point to Debian 'sid' aka
unstable)

# apt-get update 
# apt-get build-dep r-base

to make sure you you have all required packages.  You could also rebuild from
my sources via

# apt-get source r-base

or simple install the three-day old binary.

FWIW I also just rebuilt from these sources on Ubuntu Feisty at work (where
you need to adjust debian/rules and debian/control as they do not have
gcc/g++ 4.2 yet).

Hope this helps, feel free to ask Debian questions on r-sig-debian.

Cheers, Dirk

-- 
Three out of two people have difficulties with fractions.

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


Re: [Rd] partial correlation function for multivariate time series

2007-09-14 Thread Paul Gilbert
Simone Giannerini wrote:
> Dear Paul,
> 
> there is no mention to the pacf in the multivariate setting in the book 
> you suggested.

My apologies, I should have looked more carefully and realized the pacf 
discussion in Granger and Newbold is all univariate.

> As I mentioned in private I suspect that pacf() in the multivariate case 
> computes the
> partial autoregression matrix (in the terminology of Reinsel) rather 
> than the partial autocorrelation matrix

It looks like pacf() uses the calculation in stats:::ar.yw.default , so 
roughly sounds consistent with what you say. I do think parts of this 
code pre-date Reisel's book, so inconsistency with his book would 
probably be imperfect foresight.

BTW, I think bug reports with suggested fixes are usually more useful. 
And, at the very least, it seems the references in the documentation 
could be improved.

Paul Gilbert

> as the two coincide in the univariate case but are different in the 
> multivariate case as stated explicitly
> in Reisel (Sec. 3.3).
> This would explain the coefficients well above 1 (in modulus) in the 
> example I have given.
> To support my statement you can fit A VAR model to the data and compare 
> the coefficients with the results
> from pacf():
> 
> set.seed(10)
> x <- rnorm(1000,sd=1)
> y <- rnorm(1000,sd=1)
> 
> library(vars);
> mod1 <- VAR(ts(cbind(x,y)),p=4,type="none"); # fit a VAR (OLS)
> 
> ## Have a look at estimated coefficients
> 
>>  noquote(formatC(mod1$varresult$x$coefficients,format="f"))
> ## Edited by me, compare with the first column of the results below from 
> the pacf (pacf()$acf[,1,])
>  x.l1 x.l2x.l3x.l4   
>  0.0470.013   0.004   0.014
>  y.l1 y.l2y.l3y.l4  
>  374.117  72.758 -526.452 126.610
>>  noquote(formatC(mod1$varresult$y$coefficients,format="f"))
> ## Edited by me, compare with the second column of the results below 
> from the pacf (pacf()$acf[,2,])
>  x.l1x.l2 x.l3x.l4 
>  0.000   -0.000   0.000   0.000 
>  y.l1y.l2 y.l3y.l4
> -0.046   -0.025  -0.033  -0.020
> 
> pacf(ts(cbind(x,y)),plot=FALSE,lag.max=4)
> 
> Partial autocorrelations of series 'ts(cbind(x, y))', by lag
> 
> , , x
> 
>  x y   
> 0.047 ( 1)0.000 (-1)
> 0.011 ( 2)0.000 (-2)
> 0.005 ( 3)0.000 (-3)
> 0.013 ( 4)0.000 (-4)
> 
> , , y
> 
>  x y   
>   374.052 ( 1)   -0.045 ( 1)
>66.717 ( 2)   -0.024 ( 2)
>  -535.810 ( 3)   -0.031 ( 3)
>   120.802 ( 4)   -0.020 ( 4)
>  
> As you can see the coefficients fairly agree.
> I might file a bug report in some days unless someone will prove me 
> wrong before.
> 
> Regards,
> 
> Simone
> 
> 
> 
> On 11/09/2007, *Paul Gilbert* <[EMAIL PROTECTED] 
> > wrote:
> 
> I think the reference for pacf is
> 
> @BOOK{GraNew77,
>author ={Granger, C. W. J. and Newbold, Paul},
>title = {Forecasting Economic Time Series},
>publisher = {Academic Press},
>year =  1977
>}
> 
> It certainly would not be Reisel's book, as parts of the code predate
> that by many years.
> 
> Paul Gilbert
> 
> Simone Giannerini wrote:
>  > Dear all,
>  >
>  > I found the following behaviour with pacf() in the multivariate
> case,
>  >
>  > set.seed(10)
>  > x <- rnorm(1000,sd=1)
>  > y <- rnorm(1000,sd=1)
>  > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10)
>  >
>  > Partial autocorrelations of series 'cbind(x, y)', by lag
>  >
>  > , , x
>  >
>  >  x  y
>  > 0.047 (  1)0.000 ( -1)
>  > 0.011 (  2)0.000 ( -2)
>  > 0.005 (  3)0.000 ( -3)
>  > 0.013 (  4)0.000 ( -4)
>  > 0.050 (  5)0.000 ( -5)
>  > 0.034 (  6)0.000 ( -6)
>  > 0.026 (  7)0.000 ( -7)
>  >-0.029 (  8)0.000 ( -8)
>  >-0.010 (  9)0.000 ( -9)
>  >-0.013 ( 10)0.000 (-10)
>  >
>  > , , y
>  >
>  >  x  y
>  >   374.052 (  1)   -0.045 (  1)
>  >66.717 (  2)   -0.024 (  2)
>  >  -535.810 (  3)   -0.031 (  3)
>  >   120.802 (  4)   -0.020 (  4)
>  >   142.824 (  5)0.004 (  5)
>  >  -211.711 (  6)   -0.010 (  6)
>  >   201.856 (  7)0.058 (  7)
>  >   286.079 (  8)   -0.035 (  8)
>  >  -134.057 (  9)0.032 (  9)
>  >   -18.200 ( 10)0.019 ( 10)
>  >
>  > Since there are multiple ways of defining the pacf for
> multivariate time
>  > series
>  > (see e.g. G.C. Reinsel, Elements of multivariate time series
> analysis, II
>  > edition, Springer, section 3.3) and given that
>  > in ?pacf there is no reference to articles or books regarding its
>  > computation
>  > I do not know whether this behaviour is expected or it is a bug
> instead.
>  > In the first case could you provide a reference for i

Re: [Rd] problems for ./configure on Ralpha: gcc related

2007-09-14 Thread Simon Urbanek
Stéphane,

the problem is that your compiler doesn't work (as the message  
clearly tells you). You must have working compiler (and other  
development tools) before you try compiling R.

I have no clue how you managed to get such a broken compiler, because  
Debian comes with a complete, working compiler suite ... you should  
fix your OS in the first place ...

BTW according to Google Ralpha is a "Russian American Space  
Cooperation", so I wonder how you got it on your computer in the  
first place ;)

Cheers,
Simon


On Sep 14, 2007, at 10:27 AM, Stéphane Dray wrote:

> Dear all,
> I am trying to compile Ralpha on my computer (OS = Debian). SVN  
> Revision is:
>
> Revision: 42843
> Last Changed Date: 2007-09-14
>
> ./configure returns :
> 
> [EMAIL PROTECTED]:~/Rdev/R-alpha$ ./configure
> checking build system type... i686-pc-linux-gnulibc1
> checking host system type... i686-pc-linux-gnulibc1
> loading site script './config.site'
> loading build specific script './config.site'
> checking for pwd... /bin/pwd
> checking whether builddir is srcdir... yes
> checking for working aclocal... found
> checking for working autoconf... found
> checking for working automake... found
> checking for working autoheader... found
> checking for gawk... gawk
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking whether ln -s works... yes
> checking for ranlib... ranlib
> checking for bison... bison -y
> checking for ar... ar
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for sed... /bin/sed
> checking for less... /usr/bin/less
> checking for perl... /usr/bin/perl
> checking whether perl version is at least 5.8.0... yes
> checking for dvips... /usr/bin/dvips
> checking for tex... /usr/bin/tex
> checking for latex... /usr/bin/latex
> checking for makeindex... /usr/bin/makeindex
> checking for pdftex... /usr/bin/pdftex
> checking for pdflatex... /usr/bin/pdflatex
> checking for makeinfo... /usr/bin/makeinfo
> checking whether makeinfo version is at least 4.7... yes
> checking for texi2dvi... /usr/bin/texi2dvi
> checking for unzip... /usr/bin/unzip
> checking for zip... /usr/bin/zip
> checking for gzip... /bin/gzip
> checking for firefox... /usr/bin/firefox
> using default browser ... /usr/bin/firefox
> checking for acroread... /usr/bin/acroread
> checking for gcc... gcc
> checking for C compiler default output file name... configure:  
> error: C
> compiler cannot create executables
> See `config.log' for more details.
> 
> gcc  -v returns
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --enable-targets=all --disable-werror --enable-checking=release
> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.2.1 (Debian 4.2.1-3)
>
> and in the config.log, I have:
> .
> configure:4596: checking for gcc
> configure:4612: found /usr/bin/gcc
> configure:4623: result: gcc
> configure:4861: checking for C compiler version
> configure:4868: gcc --version >&5
> gcc (GCC) 4.2.1 (Debian 4.2.1-3)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.   
> There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
> PURPOSE.
>
> configure:4871: $? = 0
> configure:4878: gcc -v >&5
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --enable-targets=all --disable-werror --enable-checking=release
> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.2.1 (Debian 4.2.1-3)
> configure:4881: $? = 0
> configure:4888: gcc -V >&5
> gcc: '-V' option must have argument
> configure:4891: $? = 1
> configure:4914: checking for C compiler default output file name
> configure:4941: gcc  -I/usr/local/include -L/usr/local/lib  
> conftest.c  >&5
> /usr/bin/ld: crt1.o: No such file: No such file or directory
> collect2: ld returned 1 exit status
> configure:4944: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "R"
> | #define PACKAGE_TARNAME "R"
> | #define PACKAGE_VERSION "2.6.0"
> | #define PACKAGE_STRING

Re: [Rd] Reciprocal Mill's Ratio

2007-09-14 Thread Simone Giannerini
Dear Murray,

I think you might have to update R in first instance and provide a
reproducible example in second place so that people might help you.

Regards,

Simone



On 13/09/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I believe that this may be more appropriate here in r-devel than in
> r-help.
>
> The normal hazard function, or reciprocal Mill's Ratio, may be obtained
> in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for
> small values of z. The latter formula breaks dowm numerically for me
> (running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4
> or greater.
>
> Looking at the pnorm documentation I see that it is based on Cody (1993)
> and thence, going one step further back, on Cody (1969). Consulting
> Cody (1969) I see that the algorithm for pnorm(z) [or actually erf(z)]
> is actually based on rational function approximations for the
> reciprocal Mill's ratio itself, as I rather expected.
>
> I wonder if anyone has dug out a function for the reciprocal Mill's
> ratio out of the pnorm() code? Anticipating the obvious response I don't
> believe that this would be one of the things I might be good at!
>
> Murray Jorgensen
>
> References
>
> Cody, W. D. (1993)
> Algorithm 715: SPECFUN – A portable FORTRAN package of special function
> routines and test drivers.
> ACM Transactions on Mathematical Software 19, 22–32.
>
> Cody, W. D. (1969)
> Rational Chebyshev Approximations for the Error Function
> Mathematics of Computation, Vol. 23, No. 107. (Jul., 1969), pp. 631-637.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__

[[alternative HTML version deleted]]

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


[Rd] Reciprocal Mill's Ratio

2007-09-14 Thread maj
I believe that this may be more appropriate here in r-devel than in r-help.

The normal hazard function, or reciprocal Mill's Ratio, may be obtained
in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for
small values of z. The latter formula breaks dowm numerically for me
(running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4
or greater.

Looking at the pnorm documentation I see that it is based on Cody (1993)
and thence, going one step further back, on Cody (1969). Consulting
Cody (1969) I see that the algorithm for pnorm(z) [or actually erf(z)]
is actually based on rational function approximations for the
reciprocal Mill's ratio itself, as I rather expected.

I wonder if anyone has dug out a function for the reciprocal Mill's
ratio out of the pnorm() code? Anticipating the obvious response I don't
believe that this would be one of the things I might be good at!

Murray Jorgensen

References

Cody, W. D. (1993)
Algorithm 715: SPECFUN – A portable FORTRAN package of special function
routines and test drivers.
ACM Transactions on Mathematical Software 19, 22–32.

Cody, W. D. (1969)
Rational Chebyshev Approximations for the Error Function
Mathematics of Computation, Vol. 23, No. 107. (Jul., 1969), pp. 631-637.

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


[Rd] problems for ./configure on Ralpha: gcc related

2007-09-14 Thread Stéphane Dray
Dear all,
I am trying to compile Ralpha on my computer (OS = Debian). SVN Revision is:

Revision: 42843
Last Changed Date: 2007-09-14

./configure returns :

[EMAIL PROTECTED]:~/Rdev/R-alpha$ ./configure
checking build system type... i686-pc-linux-gnulibc1
checking host system type... i686-pc-linux-gnulibc1
loading site script './config.site'
loading build specific script './config.site'
checking for pwd... /bin/pwd
checking whether builddir is srcdir... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for gawk... gawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... bison -y
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking for sed... /bin/sed
checking for less... /usr/bin/less
checking for perl... /usr/bin/perl
checking whether perl version is at least 5.8.0... yes
checking for dvips... /usr/bin/dvips
checking for tex... /usr/bin/tex
checking for latex... /usr/bin/latex
checking for makeindex... /usr/bin/makeindex
checking for pdftex... /usr/bin/pdftex
checking for pdflatex... /usr/bin/pdflatex
checking for makeinfo... /usr/bin/makeinfo
checking whether makeinfo version is at least 4.7... yes
checking for texi2dvi... /usr/bin/texi2dvi
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for gzip... /bin/gzip
checking for firefox... /usr/bin/firefox
using default browser ... /usr/bin/firefox
checking for acroread... /usr/bin/acroread
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C 
compiler cannot create executables
See `config.log' for more details.

gcc  -v returns
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr 
--enable-targets=all --disable-werror --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-3)

and in the config.log, I have:
.
configure:4596: checking for gcc
configure:4612: found /usr/bin/gcc
configure:4623: result: gcc
configure:4861: checking for C compiler version
configure:4868: gcc --version >&5
gcc (GCC) 4.2.1 (Debian 4.2.1-3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:4871: $? = 0
configure:4878: gcc -v >&5
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr 
--enable-targets=all --disable-werror --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-3)
configure:4881: $? = 0
configure:4888: gcc -V >&5
gcc: '-V' option must have argument
configure:4891: $? = 1
configure:4914: checking for C compiler default output file name
configure:4941: gcc  -I/usr/local/include -L/usr/local/lib conftest.c  >&5
/usr/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
configure:4944: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "R"
| #define PACKAGE_TARNAME "R"
| #define PACKAGE_VERSION "2.6.0"
| #define PACKAGE_STRING "R 2.6.0"
| #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
| #define PACKAGE "R"
| #define VERSION "2.6.0"
| #define R_PLATFORM "i686-pc-linux-gnulibc1"
| #define R_CPU "i686"
| #define R_VENDOR "pc"
| #define R_OS "linux-gnulibc1"
| #define Unix 1
| #define R_ARCH ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4983: error: C compiler cannot create executables
See `config.log' for more details.
...

I did not understand what is the problem. Any idea ?

Thanks in advances,

Sincerely.


-- 

Stéphane DRAY ([EMAIL PROTECTED] )
Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - Lyon I
43, Bd du 11 Novembre 1918, 69622 Villeurbanne Cedex, France
Tel: 33 4 72 43 27 57   Fax: 33 4 72 43 13 88
http://biomserv.univ-lyon1.fr/~dray/


Re: [Rd] partial correlation function for multivariate time series

2007-09-14 Thread Simone Giannerini
Dear Paul,

there is no mention to the pacf in the multivariate setting in the book you
suggested.
As I mentioned in private I suspect that pacf() in the multivariate case
computes the
partial autoregression matrix (in the terminology of Reinsel) rather than
the partial autocorrelation matrix
as the two coincide in the univariate case but are different in the
multivariate case as stated explicitly
in Reisel (Sec. 3.3).
This would explain the coefficients well above 1 (in modulus) in the example
I have given.
To support my statement you can fit A VAR model to the data and compare the
coefficients with the results
from pacf():

set.seed(10)
x <- rnorm(1000,sd=1)
y <- rnorm(1000,sd=1)

library(vars);
mod1 <- VAR(ts(cbind(x,y)),p=4,type="none"); # fit a VAR (OLS)

## Have a look at estimated coefficients

> noquote(formatC(mod1$varresult$x$coefficients,format="f"))
## Edited by me, compare with the first column of the results below from the
pacf (pacf()$acf[,1,])
 x.l1 x.l2x.l3x.l4
 0.0470.013   0.004   0.014
 y.l1 y.l2y.l3y.l4
 374.117  72.758 -526.452 126.610
>  noquote(formatC(mod1$varresult$y$coefficients,format="f"))
## Edited by me, compare with the second column of the results below from
the pacf (pacf()$acf[,2,])
 x.l1x.l2 x.l3x.l4
 0.000   -0.000   0.000   0.000
 y.l1y.l2 y.l3y.l4
-0.046   -0.025  -0.033  -0.020

pacf(ts(cbind(x,y)),plot=FALSE,lag.max=4)

Partial autocorrelations of series 'ts(cbind(x, y))', by lag

, , x

 x y
0.047 ( 1)0.000 (-1)
0.011 ( 2)0.000 (-2)
0.005 ( 3)0.000 (-3)
0.013 ( 4)0.000 (-4)

, , y

 x y
  374.052 ( 1)   -0.045 ( 1)
   66.717 ( 2)   -0.024 ( 2)
 -535.810 ( 3)   -0.031 ( 3)
  120.802 ( 4)   -0.020 ( 4)

As you can see the coefficients fairly agree.
I might file a bug report in some days unless someone will prove me wrong
before.

Regards,

Simone



On 11/09/2007, Paul Gilbert <[EMAIL PROTECTED]> wrote:
>
> I think the reference for pacf is
>
> @BOOK{GraNew77,
>author ={Granger, C. W. J. and Newbold, Paul},
>title = {Forecasting Economic Time Series},
>publisher = {Academic Press},
>year =  1977
>}
>
> It certainly would not be Reisel's book, as parts of the code predate
> that by many years.
>
> Paul Gilbert
>
> Simone Giannerini wrote:
> > Dear all,
> >
> > I found the following behaviour with pacf() in the multivariate case,
> >
> > set.seed(10)
> > x <- rnorm(1000,sd=1)
> > y <- rnorm(1000,sd=1)
> > pacf(ts(cbind(x,y)),plot=FALSE,lag.max=10)
> >
> > Partial autocorrelations of series 'cbind(x, y)', by lag
> >
> > , , x
> >
> >  x  y
> > 0.047 (  1)0.000 ( -1)
> > 0.011 (  2)0.000 ( -2)
> > 0.005 (  3)0.000 ( -3)
> > 0.013 (  4)0.000 ( -4)
> > 0.050 (  5)0.000 ( -5)
> > 0.034 (  6)0.000 ( -6)
> > 0.026 (  7)0.000 ( -7)
> >-0.029 (  8)0.000 ( -8)
> >-0.010 (  9)0.000 ( -9)
> >-0.013 ( 10)0.000 (-10)
> >
> > , , y
> >
> >  x  y
> >   374.052 (  1)   -0.045 (  1)
> >66.717 (  2)   -0.024 (  2)
> >  -535.810 (  3)   -0.031 (  3)
> >   120.802 (  4)   -0.020 (  4)
> >   142.824 (  5)0.004 (  5)
> >  -211.711 (  6)   -0.010 (  6)
> >   201.856 (  7)0.058 (  7)
> >   286.079 (  8)   -0.035 (  8)
> >  -134.057 (  9)0.032 (  9)
> >   -18.200 ( 10)0.019 ( 10)
> >
> > Since there are multiple ways of defining the pacf for multivariate time
> > series
> > (see e.g. G.C. Reinsel, Elements of multivariate time series analysis,
> II
> > edition, Springer, section 3.3) and given that
> > in ?pacf there is no reference to articles or books regarding its
> > computation
> > I do not know whether this behaviour is expected or it is a bug instead.
> > In the first case could you provide a reference for it? In the second
> case I
> > might file a bug report.
> > Thank you for the great work you are doing for the scientific community.
> >
> > kind regards,
> >
> > Simone Giannerini
> >
> > WINDOWS
> >
> > platform   i386-pc-mingw32
> > arch   i386
> > os mingw32
> > system i386, mingw32
> > status
> > major  2
> > minor  5.1
> > year   2007
> > month  06
> > day27
> > svn rev42083
> > language   R
> > version.string R version 2.5.1 (2007-06-27)
> >
> > LINUX
> >
> >
> >>R.Version()
> >
> > $platform
> > [1] "x86_64-unknown-linux-gnu"
> >
> > $arch
> > [1] "x86_64"
> >
> > $os
> > [1] "linux-gnu"
> >
> > $system
> > [1] "x86_64, linux-gnu"
> >
> > $status
> > [1] ""
> >
> > $major
> > [1] "2"
> >
> > $minor
> > [1] "5.1"
> >
> > $year
> > [1] "2007"
> >
> > $month
> > [1] "06"
> >
> > $day
> > [1] "27"
> >
> > $`svn rev`
> > [1] "42083"
> >
> > $language
> > [1] "R"
> >
> > $version.string
> > [1] "R version 2.5.1 (2007-06-27)"
>
> ===