Re: [Rd] Identifying graphics files produced by R

[Romain Francois]

Hi,

I don't know the answer but here is how I would try to get it from the 
source:


$ cd  R-devel/src
$ grep -R "R Software" *
Binary file library/grDevices/src/grDevices.so matches
library/grDevices/src/devPS.c:fprintf(fp, "Creator: R Software\n");
Binary file library/grDevices/src/devPS.o matches

$ wc library/grDevices/src/*.c
  426   1928  10606 library/grDevices/src/chull.c
  195658   5395 library/grDevices/src/devNull.c
  775   2771  24480 library/grDevices/src/devPicTeX.c
 7592  26813 212324 library/grDevices/src/devPS.c
 1375   5342  48939 library/grDevices/src/devQuartz.c
 3401  12322 100782 library/grDevices/src/devWindows.c
   75273   2113 library/grDevices/src/init.c
  189807   7436 library/grDevices/src/qdBitmap.c
  165646   5416 library/grDevices/src/qdPDF.c
14193  51560 417491 total

Somewhere in the 14193 lines of code is your answer. Probably also worth 
looking in the  modules/X11/ and unix directories


Romain

--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr




David M Smith wrote:

Oftentimes, I see graphs on the web that *look* like they've been
produced by R, but I can never be sure.  Or can I?  I notice that
PostScript files include a "%%%Creator: R Software" line, but do R
graphics drivers encode any identifying information in GIF or PNG
files more commonly used on the web?  And of so, would such evidence
necessarily be obliterated in post-processing (e.g cropping)?

I'm trying to do an informal survey of R's use to create statistical
graphics on the web, and if there's a way to identify graph files I
see as coming from R it would help a lot.

Thanks,
# David Smith

--
David M Smith 
Director of Community, REvolution Computing www.revolution-computing.com
Tel: +1 (206) 577-4778 x3203 (Seattle, USA)



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

Re: [Rd] [PATCH] typo in R-lang

[Martin Maechler]

Thank you,  Peter;
I just have committed the fix for the typo.
(The inline patch was perfectly sufficient)

Martin Maechler, ETH Zurich

> "PC" == Peter Cowan 
> on Fri, 13 Feb 2009 20:02:28 -0800 writes:

PC> Here is a patch for a small typo in the description of do.call()

PC> in case the inline version is unsuitable:
PC> 



PC> Index: /Users/peter/manual/R-lang.texi
PC> ===
PC> --- /Users/peter/manual/R-lang.texi (revision 47919)
PC> +++ /Users/peter/manual/R-lang.texi (working copy)
PC> @@ -3683,7 +3683,7 @@
PC> used rather rarely, but is occasionally useful where the name of a
PC> function is available as a character variable.

PC> -The function @code{do.call} is related, but evaluates the call 
immediate
PC> +The function @code{do.call} is related, but evaluates the call 
immediately
PC> and takes the arguments from an object of mode @code{"list"} containing
PC> all the arguments.  A natural use of this is when one wants to apply a
PC> function like @code{cbind} to all elements of a list or data frame.

PC> __
PC> R-devel@r-project.org mailing list
PC> 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] Generate random numbers in Fortran

[Fabio Mathias]

As I am wanting to generate a beta, then I created a function in C to
generate a beta, but the problem appears when I go to compile

My function in C is

#include 
#include 
#include 

void F77_SUB(myrbeta)(double* px)
{ 
    GetRNGstate();
    *px = rbeta(1.00,3.00);
    PutRNGstate();
}

My function in Fortran is

subroutine blah(a)
double precision (a)
call myrbeta(RND)
end

The error

fmc...@fmcron-desktop:~/teste$ R CMD SHLIB mat.c blah.f
gcc -std=gnu99 -I/usr/share/R/include      -fpic  -g -O2 -c mat.c -o mat.o
gfortran   -fpic  -g -O2 -c blah.f -o blah.o
blah.f:1.1:

subroutine 
blah(a)                                                     
 
1
Erro: Non-numeric character in statement label at (1)
blah.f:1.1:

subroutine 
blah(a)                                                     
 
1
Erro: Unclassifiable statement at (1)
blah.f:2.1:

double precision 
(a)                                                   
 
1
Erro: Non-numeric character in statement label at (1)
blah.f:2.1:

double precision 
(a)                                                   
 
1
Erro: Unclassifiable statement at (1)
blah.f:4.1:

end                                                                    
 
1
Erro: Non-numeric character in statement label at (1)
blah.f:4.1:

end                                                                    
 
1
Erro: Unclassifiable statement at (1)
make: ** [blah.o] Erro 1


             Fábio Mathias 
Corrêa                       UFLA


--- Em sex, 13/2/09, Kjell Konis  escreveu:
De: Kjell Konis 
Assunto: Re: [Rd] Generate random numbers in Fortran
Para: "fabio.u...@yahoo.com.br" 
Cc: "r-devel@r-project.org" 
Data: Sexta-feira, 13 de Fevereiro de 2009, 16:49

Take a look at section 6.6 in Writing R Extensions. It describes how to call C
functions from FORTRAN. Basically it just boils down to this, in a C file define
the functions

void F77_SUB(fseedi)(void)
{
  int x = 100;
  seed_in(&x);
}


void F77_SUB(fseedo)(void)
{
  int x = 100;
  seed_out(&x);
}


void F77_SUB(myrunif)(double* px)
{
*px = unif_rand();
}


Then you could write a FORTRAN subroutine like

  subroutine blah()
  implicit double precision (a-h,o-z)
  call fseedi()
  call myrunif(RND)
  call fseedo()
  end

The fseed* subroutines only need to be called once, fseedi at the beginning of
your FORTRAN code and fseedo at the end.

HTH,
Kjell


On 13 févr. 09, at 17:32, Fabio Mathias wrote:

> Hi!!!
> It would like to know if it exists a form to use the functions to
> generate variates in FORTRAN with the same easiness I use that them in
> C? Or not?
> If yes. They would have some example? I would like to use the functions
rbeta, rlnorm and others!
> 
> 
> Sorry my english..rsrsrs
> 
> Thanks!!!
> 
> 
>  Fábio Mathias CorrêaUniversity Federal of the Lavras -
Brazil
> 
> 
> 
>  Veja quais são os assuntos do momento no Yahoo! +Buscados
> 
>   [[alternative HTML version deleted]]
> 
> 




  Veja quais são os assuntos do momento no Yahoo! +Buscados

[[alternative HTML version deleted]]

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

Re: [Rd] Generate random numbers in Fortran

[Prof Brian Ripley]

There are lots of invalid characters in your mail, but Fortran code 
starts in column 7 and that is what the compiler is telling you you 
have not done.  (Some dialects will allow tabs instead, but I see no 
sing of those either.)


If you are that unfamiliar with Fortran, why not just use C?

On Sat, 14 Feb 2009, Fabio Mathias wrote:


As I am wanting to generate a beta, then I created a function in C to
generate a beta, but the problem appears when I go to compile

My function in C is

#include 
#include 
#include 

void F77_SUB(myrbeta)(double* px)
{
?? GetRNGstate();
?? *px = rbeta(1.00,3.00);
?? PutRNGstate();
}

My function in Fortran is

subroutine blah(a)
double precision (a)
call myrbeta(RND)
end

The error

fmc...@fmcron-desktop:~/teste$ R CMD SHLIB mat.c blah.f
gcc -std=gnu99 -I/usr/share/R/include?? -fpic?? -g -O2 -c mat.c -o mat.o
gfortran -fpic?? -g -O2 -c blah.f -o blah.o
blah.f:1.1:

subroutine 
blah(a)??
1
Erro: Non-numeric character in statement label at (1)
blah.f:1.1:

subroutine 
blah(a)??
1
Erro: Unclassifiable statement at (1)
blah.f:2.1:

double precision 
(a)??
1
Erro: Non-numeric character in statement label at (1)
blah.f:2.1:

double precision 
(a)??
1
Erro: Unclassifiable statement at (1)
blah.f:4.1:

end
1
Erro: Non-numeric character in statement label at (1)
blah.f:4.1:

end
1
Erro: Unclassifiable statement at (1)
make: ** [blah.o] Erro 1


 F??bio Mathias 
Corr??a UFLA


--- Em sex, 13/2/09, Kjell Konis  escreveu:
De: Kjell Konis 
Assunto: Re: [Rd] Generate random numbers in Fortran
Para: "fabio.u...@yahoo.com.br" 
Cc: "r-devel@r-project.org" 
Data: Sexta-feira, 13 de Fevereiro de 2009, 16:49

Take a look at section 6.6 in Writing R Extensions. It describes how to call C
functions from FORTRAN. Basically it just boils down to this, in a C file define
the functions

void F77_SUB(fseedi)(void)
{
 int x = 100;
 seed_in(&x);
}


void F77_SUB(fseedo)(void)
{
 int x = 100;
 seed_out(&x);
}


void F77_SUB(myrunif)(double* px)
{
*px = unif_rand();
}


Then you could write a FORTRAN subroutine like

 subroutine blah()
 implicit double precision (a-h,o-z)
 call fseedi()
 call myrunif(RND)
 call fseedo()
 end

The fseed* subroutines only need to be called once, fseedi at the beginning of
your FORTRAN code and fseedo at the end.

HTH,
Kjell


On 13 f??vr. 09, at 17:32, Fabio Mathias wrote:


Hi!!!
It would like to know if it exists a form to use the functions to
generate variates in FORTRAN with the same easiness I use that them in
C? Or not?
If yes. They would have some example? I would like to use the functions

rbeta, rlnorm and others!



Sorry my english..rsrsrs

Thanks!!!


 F??bio Mathias Corr??aUniversity Federal of the Lavras -

Brazil




 Veja quais s??o os assuntos do momento no Yahoo! +Buscados

[[alternative HTML version deleted]]







 Veja quais s??o os assuntos do momento no Yahoo! +Buscados

[[alternative HTML version deleted]]




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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] Generate random numbers in Fortran

[Kjell Konis]

Sorry, my example was just to give you a rough idea of how to do  
this.  Here is an example that works.

myrandom.c:

#include 
#include 

void F77_SUB(fseedi)(void)
{
   GetRNGstate();
}


void F77_SUB(fseedo)(void)
{
   PutRNGstate();
}


void F77_SUB(myrbeta)(double* px, double* pa, double* pb)
{
*px = rbeta(*pa, *pb);
}


and example.f

   subroutine example(x, a, b)
   implicit double precision (a-h,o-z)
   call fseedi()
   call myrbeta(x, a, b)
   call fseedo()
   end



Note: it is important that there are 6 spaces at the beginning of  
each line.

Also, don't do this:

void F77_SUB(myrbeta)(double* px)
{
 GetRNGstate();
 *px = rbeta(1.00,3.00);
 PutRNGstate();
}

It spends more time seeding the random number generator than  
generating random numbers.

Regards,
Kjell



On Feb 14, 2009, at 11:09 AM, Fabio Mathias wrote:

> As I am wanting to generate a beta, then I created a function in C  
> to generate a beta, but the problem appears when I go to compile
>
> My function in C is
>
> #include 
> #include 
> #include 
>
> void F77_SUB(myrbeta)(double* px)
> {
> GetRNGstate();
> *px = rbeta(1.00,3.00);
> PutRNGstate();
> }
>
> My function in Fortran is
>
> subroutine blah(a)
> double precision (a)
> call myrbeta(RND)
> end
>
> The error
>
> fmc...@fmcron-desktop:~/teste$ R CMD SHLIB mat.c blah.f
> gcc -std=gnu99 -I/usr/share/R/include  -fpic  -g -O2 -c mat.c - 
> o mat.o
> gfortran   -fpic  -g -O2 -c blah.f -o blah.o
> blah.f:1.1:
>
> subroutine blah(a)
> 1
> Erro: Non-numeric character in statement label at (1)
> blah.f:1.1:
>
> subroutine blah(a)
> 1
> Erro: Unclassifiable statement at (1)
> blah.f:2.1:
>
> double precision (a)
> 1
> Erro: Non-numeric character in statement label at (1)
> blah.f:2.1:
>
> double precision (a)
> 1
> Erro: Unclassifiable statement at (1)
> blah.f:4.1:
>
> end
> 1
> Erro: Non-numeric character in statement label at (1)
> blah.f:4.1:
>
> end
> 1
> Erro: Unclassifiable statement at (1)
> make: ** [blah.o] Erro 1
>
>
>  Fábio Mathias Corrêa
>UFLA
>
>
> --- Em sex, 13/2/09, Kjell Konis  escreveu:
> De: Kjell Konis 
> Assunto: Re: [Rd] Generate random numbers in Fortran
> Para: "fabio.u...@yahoo.com.br" 
> Cc: "r-devel@r-project.org" 
> Data: Sexta-feira, 13 de Fevereiro de 2009, 16:49
>
> Take a look at section 6.6 in Writing R Extensions. It describes  
> how to call C
> functions from FORTRAN.
>
>  Basically it just boils down to this, in a C file define
> the functions
>
> void F77_SUB(fseedi)(void)
> {
>   int x = 100;
>   seed_in(&x);
> }
>
>
> void F77_SUB(fseedo)(void)
> {
>   int x = 100;
>   seed_out(&x);
> }
>
>
> void F77_SUB(myrunif)(double* px)
> {
>   *px = unif_rand();
> }
>
>
> Then you could write a FORTRAN subroutine like
>
>   subroutine blah()
>   implicit double precision (a-h,o-z)
>   call fseedi()
>   call myrunif(RND)
>   call fseedo()
>   end
>
> The fseed* subroutines only need to be called once, fseedi at the  
> beginning of
> your FORTRAN code and fseedo at the end.
>
> HTH,
> Kjell
>
>
> On 13 févr. 09, at 17:32, Fabio Mathias wrote:
>
> > Hi!!!
> > It would like to know if it exists a form to use the functions to
> > generate variates in FORTRAN with the same easiness I use that  
> them in
> > C? Or not?
> > If yes. They
>
>  would have some example? I would like to use the functions
> rbeta, rlnorm and others!
> >
> >
> > Sorry my english..rsrsrs
> >
> > Thanks!!!
> >
> >
> >  Fábio Mathias CorrêaUniversity Federal of the  
> Lavras -
> Brazil
> >
> >
> >
> >  Veja quais são os assuntos do momento no Yahoo! +Buscados
> >
> > [[alternative HTML version deleted]]
> >
> > 
>
>
> Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10  
> - Celebridades - Música - Esportes


[[alternative HTML version deleted]]

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

Re: [Rd] proposed simulate.glm method

[Nicholas Lewin-Koh]

Hi,
For extended glms such as gams, gnm or other distributions
such as negative binomial, would there need to be a separate simulate
method?
Or, could the current framework, rather than stopping with an error
look for the appropriate model matrix, coefficients, distribution
function and family object
to simulate from? 

Nicholas 


> Message: 9
> Date: Fri, 13 Feb 2009 21:27:57 +0100
> From: Martin Maechler 
> Subject: Re: [Rd] proposed simulate.glm method
> To: Heather Turner 
> Cc: r-devel@r-project.org, Martin Maechler
>   
> Message-ID: <18837.55245.15158.29...@cmath-5.math.ethz.ch>
> Content-Type: text/plain; charset=us-ascii
> 
> Thank you, Heather and Ben,
> 
> > "HT" == Heather Turner 
> > on Fri, 13 Feb 2009 15:52:37 + writes:
> 
> HT> Yes, thanks to Ben for getting the ball rolling. His
> HT> code was more streamlined than mine, pointing to further
> HT> simplifications which I've included in the extended
> HT> version below.
> 
> HT> The code for the additional families uses functions from
> HT> MASS and SuppDists - I wasn't sure about the best way to
> HT> do this, so have just used :: for now.
> 
> HT> It appears to be working happily for both glm and gnm
> HT> objects (no gnm-specific code used).
> 
> HT> Best wishes,
> 
> HT> Heather
> 
> []
> 
> I have now followed Brian Ripley's suggetion to just extend
> simulate.lm() to also deal with "glm" objects, but using
> Heather's suggestions for the different families;
> I've just commited src/library/stats/R/lm.R  with the new code.
> (get it from  svn.r-project.org/R/trunk/ or this night's R-devel
>  tarball).
> 
> One difference to your propsal: Instead of just
> object$fitted , the code is using
> fitted(object)  ... something which should properly to the na.action
> used.
> 
> For the (MASS and) SuppDists package requirement, I'm using 
> the following
> 
>   if(is.null(tryCatch(loadNamespace("SuppDists"),
> error = function(e) NULL)))
> stop("Need CRAN package 'SuppDists' for 'inverse.gaussian' family")
> 
> 
> I've not yet updated the help page for simulate(),
> and have only tested relatively few cases for binomial, poisson
> and Gamma.
> I've wanted to expose this to you, so you can provide more
> feedback and possibly even a patch to
>svn.r-project.org/R/trunk/src/library/stats/man/simulate.Rd
> 
> Martin
> 
> 
>

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

Re: [Rd] proposed simulate.glm method

[Martin Maechler]

> "NicLK" == Nicholas Lewin-Koh 
> on Sat, 14 Feb 2009 08:34:45 -0800 writes:

NicLK> Hi, For extended glms such as gams, gnm or other
NicLK> distributions such as negative binomial, would there
NicLK> need to be a separate simulate method?  

Not necessarily,  as I said, the "glm"s are now also dealt with
in simulate.lm() and Heather more or less confirmed that this
gives correct results for "gnm" objects.

For gam(), I'd strongly expect the same to apply, but there
maybe sophisticated gam() models where the result is currently
not correct.  That's, BTW, also true for  
simulate(lm(, weights), ...)

NicLK>  Or, could the current framework, rather than
NicLK> stopping with an error look for the appropriate model
NicLK> matrix, coefficients, distribution function and
NicLK> family object to simulate from?

What do you mean?
A situation where there's no supported 'family'
or a situation where  predict() does not work as it's
supposed in the current framework,
or 

If there are such cases, we'd have to consider them together
with the corresponding package author.  It may often make sense
fthen that the author changes his methods {predict(), ..} such
that the (now) extended simulate.lm() will work automatically;
Alternatively, the author can provide  simulate.().

But I'm not sure I'm answering the question you've asked..
Martin

NicLK> Nicholas


>> Message: 9 Date: Fri, 13 Feb 2009 21:27:57 +0100 From:
>> Martin Maechler  Subject: Re:
>> [Rd] proposed simulate.glm method To: Heather Turner
>>  Cc: r-devel@r-project.org,
>> Martin Maechler  Message-ID:
>> <18837.55245.15158.29...@cmath-5.math.ethz.ch>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> Thank you, Heather and Ben,
>> 
>> > "HT" == Heather Turner
>>  > on Fri, 13 Feb 2009
>> 15:52:37 + writes:
>> 
HT> Yes, thanks to Ben for getting the ball rolling. His
HT> code was more streamlined than mine, pointing to further
HT> simplifications which I've included in the extended
HT> version below.
>> 
HT> The code for the additional families uses functions from
HT> MASS and SuppDists - I wasn't sure about the best way to
HT> do this, so have just used :: for now.
>> 
HT> It appears to be working happily for both glm and gnm
HT> objects (no gnm-specific code used).
>> 
HT> Best wishes,
>> 
HT> Heather
>> 
>> []
>> 
>> I have now followed Brian Ripley's suggetion to just
>> extend simulate.lm() to also deal with "glm" objects, but
>> using Heather's suggestions for the different families;
>> I've just commited src/library/stats/R/lm.R with the new
>> code.  (get it from svn.r-project.org/R/trunk/ or this
>> night's R-devel tarball).
>> 
>> One difference to your propsal: Instead of just
>> object$fitted , the code is using fitted(object)
>> ... something which should properly to the na.action
>> used.
>> 
>> For the (MASS and) SuppDists package requirement, I'm
>> using the following
>> 
>> if(is.null(tryCatch(loadNamespace("SuppDists"), error =
>> function(e) NULL))) stop("Need CRAN package 'SuppDists'
>> for 'inverse.gaussian' family")
>> 
>> 
>> I've not yet updated the help page for simulate(), and
>> have only tested relatively few cases for binomial,
>> poisson and Gamma.  I've wanted to expose this to you, so
>> you can provide more feedback and possibly even a patch
>> to
>> svn.r-project.org/R/trunk/src/library/stats/man/simulate.Rd
>> 
>> Martin
>> 
>> 
>> 

__
NicLK> R-devel@r-project.org mailing list
NicLK> 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] proposed simulate.glm method

[Nicholas Lewin-Koh]

Hi,
Well, my question wasn't that clear :-), but yes you mostly answered it.
I guess
the one case I would be concerned is in Heather's code, where the
distribution
to simulate from is chosen, that seemed to be hard coded. So if 
I built a family object, say for a model that assumes errors from a zipf
distribution,
and I did have a predict method (which is a fair assumption) would that
fail because the rzipf function would not be accessed?

Nicholas 
On Sat, 14 Feb 2009 20:10:26 +0100, "Martin Maechler"
 said:
> > "NicLK" == Nicholas Lewin-Koh 
> > on Sat, 14 Feb 2009 08:34:45 -0800 writes:
> 
> NicLK> Hi, For extended glms such as gams, gnm or other
> NicLK> distributions such as negative binomial, would there
> NicLK> need to be a separate simulate method?  
> 
> Not necessarily,  as I said, the "glm"s are now also dealt with
> in simulate.lm() and Heather more or less confirmed that this
> gives correct results for "gnm" objects.
> 
> For gam(), I'd strongly expect the same to apply, but there
> maybe sophisticated gam() models where the result is currently
> not correct.  That's, BTW, also true for  
> simulate(lm(, weights), ...)
> 
> NicLK>  Or, could the current framework, rather than
> NicLK> stopping with an error look for the appropriate model
> NicLK> matrix, coefficients, distribution function and
> NicLK> family object to simulate from?
> 
> What do you mean?
> A situation where there's no supported 'family'
> or a situation where  predict() does not work as it's
> supposed in the current framework,
> or 
> 
> If there are such cases, we'd have to consider them together
> with the corresponding package author.  It may often make sense
> fthen that the author changes his methods {predict(), ..} such
> that the (now) extended simulate.lm() will work automatically;
> Alternatively, the author can provide  simulate.().
> 
> But I'm not sure I'm answering the question you've asked..
> Martin
> 
> NicLK> Nicholas
> 
> 
> >> Message: 9 Date: Fri, 13 Feb 2009 21:27:57 +0100 From:
> >> Martin Maechler  Subject: Re:
> >> [Rd] proposed simulate.glm method To: Heather Turner
> >>  Cc: r-devel@r-project.org,
> >> Martin Maechler  Message-ID:
> >> <18837.55245.15158.29...@cmath-5.math.ethz.ch>
> >> Content-Type: text/plain; charset=us-ascii
> >> 
> >> Thank you, Heather and Ben,
> >> 
> >> > "HT" == Heather Turner
> >>  > on Fri, 13 Feb 2009
> >> 15:52:37 + writes:
> >> 
> HT> Yes, thanks to Ben for getting the ball rolling. His
> HT> code was more streamlined than mine, pointing to further
> HT> simplifications which I've included in the extended
> HT> version below.
> >> 
> HT> The code for the additional families uses functions from
> HT> MASS and SuppDists - I wasn't sure about the best way to
> HT> do this, so have just used :: for now.
> >> 
> HT> It appears to be working happily for both glm and gnm
> HT> objects (no gnm-specific code used).
> >> 
> HT> Best wishes,
> >> 
> HT> Heather
> >> 
> >> []
> >> 
> >> I have now followed Brian Ripley's suggetion to just
> >> extend simulate.lm() to also deal with "glm" objects, but
> >> using Heather's suggestions for the different families;
> >> I've just commited src/library/stats/R/lm.R with the new
> >> code.  (get it from svn.r-project.org/R/trunk/ or this
> >> night's R-devel tarball).
> >> 
> >> One difference to your propsal: Instead of just
> >> object$fitted , the code is using fitted(object)
> >> ... something which should properly to the na.action
> >> used.
> >> 
> >> For the (MASS and) SuppDists package requirement, I'm
> >> using the following
> >> 
> >> if(is.null(tryCatch(loadNamespace("SuppDists"), error =
> >> function(e) NULL))) stop("Need CRAN package 'SuppDists'
> >> for 'inverse.gaussian' family")
> >> 
> >> 
> >> I've not yet updated the help page for simulate(), and
> >> have only tested relatively few cases for binomial,
> >> poisson and Gamma.  I've wanted to expose this to you, so
> >> you can provide more feedback and possibly even a patch
> >> to
> >> svn.r-project.org/R/trunk/src/library/stats/man/simulate.Rd
> >> 
> >> Martin
> >> 
> >> 
> >> 
> 
> __
> NicLK> R-devel@r-project.org mailing list
> NicLK> 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] Generate random numbers in Fortran

[Ben Bolker]

Wacek Kusnierczyk  idi.ntnu.no> writes:

> 
> you can always try to get hold of the extensive nag fortran libraries:
> 
> http://www.nag.co.uk/numeric/fl/FLdescription.asp
> 
> comsider also 'numerical recipes' by press et al., of which there are
> fortran, c, and c++ editions (i think there was a pascal edition too),
> and where there are a choice of routines for random number generation,
> statistics, and much more.  a good read, too.
> 
> vQ

  If one can get the R routines to work, I think they have some
advantages over NAG and Numerical Recipes routines:
 
  * source code is freely redistributable
  * I can't really claim expertise, but I believe there
has been some controversy (see the wikipedia page on NR,
http://en.wikipedia.org/wiki/Numerical_Recipes )

  The big advantage of NR is not in the algorithms, but
in the explanations in the book ...
  
  (The wikipedia page also refers to the Gnu Scientific Library,
which might be another set of options.)

  Ben Bolker

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

Re: [Rd] Generate random numbers in Fortran

[Ben Bolker]

Ben Bolker  ufl.edu> writes:

> > vQ
> 
>   If one can get the R routines to work, I think they have some
> advantages over NAG and Numerical Recipes routines:
> 
>   * source code is freely redistributable
>   * I can't really claim expertise, but I believe there
> has been some controversy (see the wikipedia page on NR,
> http://en.wikipedia.org/wiki/Numerical_Recipes )
> 
>   The big advantage of NR is not in the algorithms, but
> in the explanations in the book ...
> 
>   (The wikipedia page also refers to the Gnu Scientific Library,
> which might be another set of options.)
> 
>   Ben Bolker
> 
> __


  PS (replying to myself) there's an eloquent criticism
of NR's licensing policies at
http://www.astro.umd.edu/~bjw/software/boycottnr.html
which articulates a lot of my complaints better than I could

  Ben

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

Re: [Rd] proposed simulate.glm method

[Prof Brian Ripley]

On Sat, 14 Feb 2009, Nicholas Lewin-Koh wrote:

Well, my question wasn't that clear :-), but yes you mostly answered 
it. I guess the one case I would be concerned is in Heather's code, 
where the distribution to simulate from is chosen, that seemed to be 
hard coded.


Rather, all known glm families in R that correspond to actual 
probability distributions are listed.


So if I built a family object, say for a model that assumes errors 
from a zipf distribution,


Hmm, plese explain how you get that into the GLM framework -- it is 
pretty restrictive.



and I did have a predict method (which is a fair assumption) would that
fail because the rzipf function would not be accessed?


glm has a predict method, so why do you need one?  Families do not 
create additional classes of fit objects.


We could extend the definition of a family to have a 'simulate' 
element, but then existing user-contributed families (principally the 
negative binomial) would not have one and so this would not solve the 
problem .


If you know of an actual R implementation of another glm family that 
looks generally useful we'll consider adding it (but it seems that the 
end user could also do so rather easily).




Nicholas
On Sat, 14 Feb 2009 20:10:26 +0100, "Martin Maechler"
 said:

"NicLK" == Nicholas Lewin-Koh 
on Sat, 14 Feb 2009 08:34:45 -0800 writes:


NicLK> Hi, For extended glms such as gams, gnm or other
NicLK> distributions such as negative binomial, would there
NicLK> need to be a separate simulate method?

Not necessarily,  as I said, the "glm"s are now also dealt with
in simulate.lm() and Heather more or less confirmed that this
gives correct results for "gnm" objects.

For gam(), I'd strongly expect the same to apply, but there
maybe sophisticated gam() models where the result is currently
not correct.  That's, BTW, also true for
simulate(lm(, weights), ...)

NicLK>  Or, could the current framework, rather than
NicLK> stopping with an error look for the appropriate model
NicLK> matrix, coefficients, distribution function and
NicLK> family object to simulate from?

What do you mean?
A situation where there's no supported 'family'
or a situation where  predict() does not work as it's
supposed in the current framework,
or 

If there are such cases, we'd have to consider them together
with the corresponding package author.  It may often make sense
fthen that the author changes his methods {predict(), ..} such
that the (now) extended simulate.lm() will work automatically;
Alternatively, the author can provide  simulate.().

But I'm not sure I'm answering the question you've asked..
Martin

NicLK> Nicholas


   >> Message: 9 Date: Fri, 13 Feb 2009 21:27:57 +0100 From:
   >> Martin Maechler  Subject: Re:
   >> [Rd] proposed simulate.glm method To: Heather Turner
   >>  Cc: r-devel@r-project.org,
   >> Martin Maechler  Message-ID:
   >> <18837.55245.15158.29...@cmath-5.math.ethz.ch>
   >> Content-Type: text/plain; charset=us-ascii
   >>
   >> Thank you, Heather and Ben,
   >>
   >>> "HT" == Heather Turner
   >>  > on Fri, 13 Feb 2009
   >> 15:52:37 + writes:
   >>
HT> Yes, thanks to Ben for getting the ball rolling. His
HT> code was more streamlined than mine, pointing to further
HT> simplifications which I've included in the extended
HT> version below.
   >>
HT> The code for the additional families uses functions from
HT> MASS and SuppDists - I wasn't sure about the best way to
HT> do this, so have just used :: for now.
   >>
HT> It appears to be working happily for both glm and gnm
HT> objects (no gnm-specific code used).
   >>
HT> Best wishes,
   >>
HT> Heather
   >>
   >> []
   >>
   >> I have now followed Brian Ripley's suggetion to just
   >> extend simulate.lm() to also deal with "glm" objects, but
   >> using Heather's suggestions for the different families;
   >> I've just commited src/library/stats/R/lm.R with the new
   >> code.  (get it from svn.r-project.org/R/trunk/ or this
   >> night's R-devel tarball).
   >>
   >> One difference to your propsal: Instead of just
   >> object$fitted , the code is using fitted(object)
   >> ... something which should properly to the na.action
   >> used.
   >>
   >> For the (MASS and) SuppDists package requirement, I'm
   >> using the following
   >>
   >> if(is.null(tryCatch(loadNamespace("SuppDists"), error =
   >> function(e) NULL))) stop("Need CRAN package 'SuppDists'
   >> for 'inverse.gaussian' family")
   >>
   >>
   >> I've not yet updated the help page for simulate(), and
   >> have only tested relatively few cases for binomial,
   >> poisson and Gamma.  I've wanted to expose this to you, so
   >> you can provide more feedback and possibly even a patch
   >> to
   >> svn.r-project.org/R/trunk/src/library/stats/man/simulate.Rd
   >>
   >> Martin
   >>
   >>
   >>

__
NicLK> R-devel@r-project.org mailing list
  

[Rd] SET_VECTOR_ELT and STRSXPs

[Kasper Daniel Hansen]

It seems (based on the NEWS file and on output from R CMD check) that  
we may no longer use SET_VECTOR_ELT on STRSXPs. So I guess that  
section 5.14 of R-extensions needs to be updated, the current phrasing  
is
"By default a certain amount of misuse is allowed where the internal  
representation is the same: for example LOGICAL can be used on a  
INTSXP and SET_VECTOR_ELT on a STRSXP"

which indicates that it is allowed to do so.

I also suggest to change the error message in line 2648-2649 of src/ 
main/memory.c from

  SET_VECTOR_ELT() can only be applied to a 'list', not a '%s'
to
  SET_VECTOR_ELT() / SET_ELEMENT() can only be applied to a 'list',  
not a '%s'
I guess I ought to have remembered that the two macros are synonymous,  
but I didn't and it took me a while to realize this when I tried to  
fix some code written by another person (who preferred to use  
SET_ELEMENT).


Kasper

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