Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Guillaume Yziquel 

Simon Urbanek a écrit :


On Nov 30, 2009, at 16:07 , Guillaume Yziquel wrote:


Simon Urbanek a écrit :


And it goes then to my other question: How can you pass to eval a 
LANGSXP where the CAR is an *anonymous* function, no SYMSXP involved?
You just pass it as value of the call. I suspect the reason it 
doesn't work is in your code, not in the facility (note that the link 
above is useless since the construction is mystery - if you were 
constructing it right, it would work ;)).


The small example you gave just works out fine with the framework I've 
been building so far:



yziq...@seldon:~$ ocaml-batteries
Objective Caml version 3.11.1

  _
 |   | |   |
[| + | | Batteries Included  - |
 |___|_|___|
  _
 |   | |   |
 | -Type '#help;;'   | | + |]
 |___|_|___|


# #require "R.interpreter";;
# let show x = R.Pretty.t_of_sexp x;;
val show : R.sexp -> R.PrettyTypes.t = 
# open R.PrettyTypes;;


This is administrativia.


# let r_f_unevaluated = R.parse_sexp "function(x) x + 1";;
val r_f_unevaluated : R.sexp = 
# let r_f = R.eval_langsxp r_f_unevaluated;;
val r_f : R.sexp = 
# show r_f_unevaluated;;
- : R.PrettyTypes.t =
CALL (SYMBOL (Some ("function", SPECIAL)),
 [(NULL, LIST [(ARG "x", PLACE)]);
  (NULL,
   CALL (SYMBOL (Some ("+", BUILTIN)), [(NULL, ARG "x"); (NULL, Unknown)]));
  (NULL, STRINGS ["function(x) x + 1"])])
# show r_f;;
- : R.PrettyTypes.t =
CLOSURE
 {formals = LIST [(ARG "x", PLACE)];
  clos_env = ENV {frame = NULL; hashtab = NULL}}


So after evaluating the parsed output of "function(x) x + 1", you indeed 
get a pure closure. So far so good.



# let x = R.parse_sexp "11";;
val x : R.sexp = 
# R.sexptype x;;
- : R.sexptype = R.RealSxp


Here's the argument, 11.


# let call = R.langsxp_of_list [r_f; x] 2;;
val call : R.lang R.sxp = 
# show call;;
- : R.PrettyTypes.t =
CALL
 (CLOSURE
   {formals = LIST [(ARG "x", PLACE)];
clos_env = ENV {frame = NULL; hashtab = NULL}},
 [(NULL, Unknown)])


Here's the call that is built out of the closure and 11. For 
construction details, the C function is given at the bottom.



# let y = R.eval_langsxp call;;
val y : R.sexp = 


And it gets correctly evaluated. So this is fine. In fact, it works on 
the majority of the things I try. So I guess I've been building it fine. 
What's not fine is the following, from the quantmod package:



# let s = R.string "YHOO";;
val s : string R.t = 


s is a STRSXP vector containing only one string: "YHOO".


# let g = R.force (R.symbol "getSymbols");;
val g : 'a R.t = 


g is the getSymbols function from quantmod. From the help(getSymbols) 
invocation:



Usage:

 getSymbols(Symbols = NULL, 
env = .GlobalEnv,

reload.Symbols = FALSE,
verbose = FALSE,
warnings = TRUE,
src = "yahoo",
symbol.lookup = TRUE,
auto.assign = TRUE,
...)


So I try out getSymbols("YHOO"). It works out fine, and returns silently 
in the R toplevel.


But, from my binding:


# R.eval_langsxp (R.langsxp_of_list [g; s] 2);;
Erreur dans as.character(sc[[1]]) : 
  cannot coerce type 'closure' to vector of type 'character'

Exception: Failure "OCaml-R error in r_eval_sxp C stub.".


Here are the values of s and g:


# show s;;
- : R.PrettyTypes.t = STRINGS ["YHOO"]
# show g;;
- : R.PrettyTypes.t =
CLOSURE
 {formals =
   LIST
[(ARG "Symbols", NULL); (ARG "env", Unknown);
 (ARG "reload.Symbols", Unknown); (ARG "verbose", Unknown);
 (Unknown, Unknown); (ARG "src", STRINGS ["yahoo"]);
 (ARG "symbol.lookup", Unknown); (ARG "auto.assign", Unknown);
 (ARG "...", PLACE)];
  clos_env = ENV {frame = NULL; hashtab = Unknown}}


For the sake of exhaustivity, here's the C functions that I wrote to 
make function calls:



CAMLprim value r_eval_sxp (value sexp_list) {
  CAMLparam1(sexp_list);
  SEXP e;
  int error = 0;
  PROTECT(e = R_tryEval(Sexp_val(sexp_list), R_GlobalEnv, &error));
  UNPROTECT(1);
  if (error) caml_failwith("OCaml-R error in r_eval_sxp C stub.");
  CAMLreturn(Val_sexp(e));
}


and


CAMLprim value r_langsxp_of_list (value l, value n) {
  CAMLparam2(l, n);
  CAMLlocal1(l_cursor);
  SEXP s, t;
  PROTECT(t = s = Rf_allocList(Int_val(n)));
  SET_TYPEOF(s, LANGSXP);
  int first_time = 1;
  l_cursor = l;
  while (l_cursor && Is_block(l_cursor)) {
if (first_time) {first_time = 0;} else {t = CDR(t);}
SETCAR(t, Sexp_val(Field(l_cursor, 0)));
l_cursor = Field(l_cursor, 1);
  }
  UNPROTECT(1);
  CAMLreturn(Val_sexp(s));
}


So I'm almost constructing LANGSXP lists in the way you do.

One last thing, concerning the use of promises. If I do install, 
findVar, without forcing the resulting promise, and then construct the 
call, I get a failure:



# R.eval_langsxp (R.langsxp_of_list [(

Re: [Rd] Bug in R evaluating a huge instruction (PR#14096)

2009-12-01 Thread Jean Couteau 

Thanks for your time Duncan,

I join here the instruction that is not correct, hoping that might help 
you. The file is encoded in utf-8 so you should not have any problem 
reading it.


I doubt to that it is an R bug too, but with all my tests i am less and 
less sure of that.


Best regards,
Jean Couteau


Your message has encoding problems, so it's not readable.  Could you 
put the code online somewhere where we could download it in its 
original form?  I doubt if this is an R bug, but I can't point out the 
problem in your code (or confirm that it really is an R bug) without 
an undamaged copy of the code.


Duncan Murdoch





a<-morris(model=NULL,factors=c("PecheAmateurs 
décembre.proportionMetier","PechePetitMetierMer 
mai.proportionMetier","PecheAmateurs mai.proportionMetier","PecheChalutiere 
janvier.minInactivityDays","PechePetitMetierEtang 
octobre.minInactivityDays","PechePetitMetierEtang 
décembre.minInactivityDays","FiletMer.standardisationFactor","PecheAmateurs 
juin.minInactivityDays","PechePetitMetierEtang 
novembre.minInactivityDays","PechePetitMetierMer 
septembre.minInactivityDays","PechePetitMetierMer 
avril.minInactivityDays","PecheAmateurs 
août.proportionMetier","PecheChalutiere 
novembre.minInactivityDays","PechePetitMetierMer 
février.proportionMetier","PecheChalutiere 
juillet.minInactivityDays","PechePetitMetierMer octobre.proportionMetier","CSar 
Groupe 5.reproductionRate","PechePetitMetierMer 
août.proportionMetier","PechePetitMetierMer 
janvier.minInactivityDays","PechePetitMetierEtang 
mai.minInactivityDays","PecheAmateurs octobre.minInactivityDays","PecheAmateurs 
septembre.minInactivityDays","PecheChalutiere 
juin.minInactivityDays","PecheChalutiere 
avril.minInactivityDays","PecheAmateurs 
juillet.proportionMetier","PecheChalutiere 
mai.minInactivityDays","PechePetitMetierEtang 
septembre.minInactivityDays","PechePetitMetierMer 
janvier.proportionMetier","PecheAmateurs 
septembre.proportionMetier","PechePetitMetierEtang 
février.minInactivityDays","PechePetitMetierEtang 
mars.minInactivityDays","PechePetitMetierEtang 
juillet.minInactivityDays","PechePetitMetierMer 
septembre.proportionMetier","CSar.capturability","PechePetitMetierMer 
juin.proportionMetier","PecheChalutiere 
mars.minInactivityDays","PecheChalutiere 
septembre.minInactivityDays","PecheAmateurs 
janvier.minInactivityDays","PechePetitMetierMer 
août.minInactivityDays","PechePetitMetierMer 
juillet.proportionMetier","PecheChalutiere 
décembre.minInactivityDays","PecheAmateurs 
avril.minInactivityDays","PecheAmateurs 
mars.proportionMetier","PechePetitMetierMer 
novembre.minInactivityDays","PechePetitMetierEtang 
août.minInactivityDays","CSar.recruitmentDistribution","PecheChalutiere 
février.minInactivityDays","CSar.naturalDeathRate","PecheAmateurs 
octobre.proportionMetier","PechePetitMetierMer 
mai.minInactivityDays","PechePetitMetierMer 
mars.proportionMetier","PecheAmateurs 
août.minInactivityDays","FiletEtang.standardisationFactor","PecheChalutiere 
août.minInactivityDays","PecheAmateurs 
janvier.proportionMetier","PecheAmateurs 
décembre.minInactivityDays","PechePetitMetierEtang 
avril.minInactivityDays","PecheAmateurs 
mars.minInactivityDays","PechePetitMetierMer 
décembre.minInactivityDays","PecheAmateurs 
mai.minInactivityDays","PechePetitMetierEtang 
juin.minInactivityDays","Harpon.standardisationFactor","PecheAmateurs 
novembre.minInactivityDays","PecheAmateurs 
novembre.proportionMetier","PechePetitMetierMer 
mars.minInactivityDays","Ligneemb.standardisationFactor","PecheAmateurs 
juin.proportionMetier","PecheAmateurs 
avril.proportionMetier","PechePetitMetierMer 
juillet.minInactivityDays","PechePetitMetierMer 
avril.proportionMetier","PechePetitMetierMer 
octobre.minInactivityDays","PechePetitMetierMer 
février.minInactivityDays","PecheAmateurs 
juillet.minInactivityDays","PechePetitMetierMer 
décembre.proportionMetier","PecheAmateurs 
février.proportionMetier","PecheChalutiere octobre.minInactivityDays","CSar 
Groupe 4.reproductionRate","CSar Groupe 
7.reproductionRate","Lignecote.standardisationFactor","CSar.meanWeight","CSar 
Groupe 6.reproductionRate","PechePetitMetierMer 
juin.minInactivityDays","PechePetitMetierMer 
novembre.proportionMetier","PechePetitMetierEtang 
janvier.minInactivityDays","PecheAmateurs 
février.minInactivityDays","CSar.growth"),r=10,design=list(type="oat",levels=c(5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5),grid.jump=c(2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2)),binf=c(0.0,0.0,0.0,11.0,10.0,12.0,0.06,10.0,11.0,0.0,0.0,0.0,10.0,0.0,11.0,0.0,1120.0,0.0,10.0,22.0,12.0,10.0,10.0,11.0,0.0,11.0,15.0,0.0,0.0,23.0,16.0,22.0,0.0,0.0,0.0,11.0,10.0,18.0,0.0,0.0,11.0,11.0,0.0,3.0,22.0,0.0,8.0,0.0,0.0,0.0,0

Re: [Rd] raster support in graphics devices

2009-12-01 Thread Martin Maechler 
> "CM" == Charlotte Maia 
> on Tue, 1 Dec 2009 17:48:33 +1300 writes:

CM> Hi,
CM> I consider raster graphics highly problematic in statistics.
CM> People get caught up in the idea of creating pretty pictures, rather
CM> than effectively visualising information.

CM> Plus a lot of people (who should know better) needlessly put raster
CM> images inside reports and articles (even books), which either makes
CM> the files large (and very difficult to view), or creates blurry
CM> images, or both.

CM> It's always good to have more functionality.

Yes indeed, and Paul has to be thanked loudly and heartfully and
very much for providing it in the realm of graphics !!!

CM> However, I certainly hope that most of the R community stick to vector
CM> graphics (with conservative colour use), unless it is absolutely
CM> necessary to do otherwise

I agree with your reasoning *pro* using vector graphics
as much as possible, and warning against the overuse of raster
graphics in scientific work !

CM> necessary to do otherwise (and the only example I can think of, is
CM> modelling images themselves).

Did you look at the interesting page Paul sent the URL for,
http://developer.r-project.org/Raster/raster-RFC.html ?

Yes, modelling images is probably *the* most important
application area, but *fast* direct plotting of a large matrix,
mapping one matrix entry A_{i,j} to one pixel is also quite
attractive, and the Matrix package authors (me being one) are
quite interested to eventually see a version of 
  lattice::levelplot()  that builds on Paul's new
  grid::grid.raster() or grid::rasterGrob()  functions.


CM> On a side issue, I have found that R plots tend to be getting slower
CM> over the years.

CM> I think cairo was a bad move, however that's just my opinion...

Dear me...  
using Cairo features for X11 graphics is just the new default,
so users notice the nice new possibilities !
If you want the very fast (but not so very nice looking)
previous default X11() graphics, please do read the help pages:
-->  ?X11  
-->  ?X11.options
and then either  X11.options(type = "Xlib")
or   X11(type = "Xlib")

will give you the very fast (non-aliased, no alpha blending)
X11 graphics that used to be the only one in R originally.

Martin Maechler, ETH Zurich

CM> regards
CM> -- 
CM> Charlotte Maia
CM> http://sites.google.com/site/maiagx/home

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

Re: [Rd] Bug in R evaluating a huge instruction (PR#14096)

2009-12-01 Thread Romain Francois 


Hello,

Since we don't have the morris function, I have tested using this one:

> morris <- function(...) lapply(list(...), str )

If I just copy and paste into the console, R waits for more input, but 
if I parse the file, it is fine:


> eval( parse( "morrisError.R" ) )
 NULL
 chr [1:86] "PecheAmateurs décembre.proportionMetier" ...
 num 10
List of 3
 $ type : chr "oat"
 $ levels   : num [1:86] 5 5 5 5 5 5 5 5 5 5 ...
 $ grid.jump: num [1:86] 2 2 2 2 2 2 2 2 2 2 ...
 num [1:86] 0 0 0 11 10 12 0.06 10 11 0 ...
 num [1:86] 1 1 1 15 14 16 0.09 14 15 2 ...


Also fine if I source the file:

> a<-morris(model=NULL,factors=c("PecheAmateurs 
décembre.proportionMetier","PechePetitMetierMer 
mai.proportionMetier","PecheAmateurs mai.proportionMet ..." ... [TRUNCATED]

 NULL
 chr [1:86] "PecheAmateurs décembre.proportionMetier" ...
 num 10
List of 3
 $ type : chr "oat"
 $ levels   : num [1:86] 5 5 5 5 5 5 5 5 5 5 ...
 $ grid.jump: num [1:86] 2 2 2 2 2 2 2 2 2 2 ...
 num [1:86] 0 0 0 11 10 12 0.06 10 11 0 ...
 num [1:86] 1 1 1 15 14 16 0.09 14 15 2 ...


I think the limit imposed by the R_ParseBuffer function (in gram.y) is 
1024 characters.


Romain


On 12/01/2009 06:50 AM, Jean Couteau wrote:

Thanks for your time Duncan,

I join here the instruction that is not correct, hoping that might help
you. The file is encoded in utf-8 so you should not have any problem
reading it.

I doubt to that it is an R bug too, but with all my tests i am less and
less sure of that.

Best regards,
Jean Couteau


Your message has encoding problems, so it's not readable. Could you
put the code online somewhere where we could download it in its
original form? I doubt if this is an R bug, but I can't point out the
problem in your code (or confirm that it really is an R bug) without
an undamaged copy of the code.

Duncan Murdoch



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/FtUu : new package : highlight
|- http://tr.im/EAD5 : LondonR slides
`- http://tr.im/BcPw : celebrating R commit #5

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

Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Guillaume Yziquel 

Guillaume Yziquel a écrit :


One last thing, concerning the use of promises. If I do install, 
findVar, without forcing the resulting promise, and then construct the 
call, I get a failure:


# R.eval_langsxp (R.langsxp_of_list [(R.symbol "str"); (R.symbol 
"lm")] 2);;
Erreur dans function (object, ...)  :   function générique incorrecte 
dans 'UseMethod'

Exception: Failure "OCaml-R error in r_eval_sxp C stub.".


If I force the promises:

# R.eval_langsxp (R.langsxp_of_list [(R.force (R.symbol "str")); 
(R.force (R.symbol "lm"))] 2);;
function (formula, data, subset, weights, na.action, method = "qr", 
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE, 
contrasts = NULL, offset, ...)  - : R.sexp = 


It works.

So you may say that "I'm not constructing it right", I still believe 
that describing precisely what kind of arguments is accepted by eval 
would a good thing.


It seems that Matjaz Kukar had the same kind of issue that I have with 
usemethod:


http://tolstoy.newcastle.edu.au/R/devel/04/10/0902.html

I just remark two things from the resulting thread:

-1- He asks where to find a more precise documentation of the R API, 
which is also something I'd be looking for,


-2- He has been suggested to use findVar1, which doesn't seem to be part 
of the API.


Will be looking into findVar1, findFun, findVar, though I do not 
understand why this fails in my case. Please feel free to enlighten me.


All the best,

--
 Guillaume Yziquel
http://yziquel.homelinux.org/

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

Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Guillaume Yziquel 

Guillaume Yziquel a écrit :

Guillaume Yziquel a écrit :


One last thing, concerning the use of promises. If I do install, 
findVar, without forcing the resulting promise, and then construct the 
call, I get a failure:


Replacing findfun by findvar works in this specific case. See below.

Could someone explain why findfun works while findvar doesn't? I've been 
looking at the source code in envir.c, and it isn't really clear why one 
way works while the other doesn't.


Is it possible, given a variable/function name, to determine if it 
should use findFun or findVar? This would be helpful for the polymorphic 
static typing of R values.



yziq...@seldon:~/git/ocamlr-quantmod$ ocaml-batteries
Objective Caml version 3.11.1

  _
 |   | |   |
[| + | | Batteries Included  - |
 |___|_|___|
  _
 |   | |   |
 | -Type '#help;;'   | | + |]
 |___|_|___|


# #require "R.interpreter";;
# let show = R.Pretty.t_of_sexp;;
val show : R.sexp -> R.PrettyTypes.t = 


findFun works.


# let str = R.findfun (R.install "str");;
val str : ('_a -> 'b) R.t = 
# let lm = R.findvar (R.install "lm");;
val lm : 'a R.promise = 
# R.eval [str; lm];;
function (formula, data, subset, weights, na.action, method = "qr", 
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE, 
contrasts = NULL, offset, ...)  
- : R.sexp = 


findVar doesn't.


# let str = R.findvar (R.install "str");;
val str : 'a R.promise = 
# R.eval [str; lm];;
Erreur dans function (object, ...)  : 
  function générique incorrecte dans 'UseMethod'

Exception: Failure "OCaml-R error in r_eval_sxp C stub.".
# 


All the best,

--
 Guillaume Yziquel
http://yziquel.homelinux.org/

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

Re: [Rd] raster support in graphics devices

2009-12-01 Thread Simon Urbanek 

Charlotte,

On Nov 30, 2009, at 23:48 , Charlotte Maia wrote:


I consider raster graphics highly problematic in statistics.
People get caught up in the idea of creating pretty pictures, rather
than effectively visualising information.

Plus a lot of people (who should know better) needlessly put raster
images inside reports and articles (even books), which either makes
the files large (and very difficult to view), or creates blurry
images, or both.



I would like to point out that implicitly you have been already using  
raster graphics all the time in very inefficient form in heatmaps etc.  
The point here is not really about added functionality for the user  
but efficiency, because now we can finally use efficient encoding of  
heatmaps, matrix visualizations, overlay data over satellite images  
etc. Although all this was always possible in R, it was very  
inefficient and caused unwanted side effects (see the constant anti- 
aliasing discussions).


Cheers,
Simon



It's always good to have more functionality.
However, I certainly hope that most of the R community stick to vector
graphics (with conservative colour use), unless it is absolutely
necessary to do otherwise (and the only example I can think of, is
modelling images themselves).

On a side issue, I have found that R plots tend to be getting slower
over the years.
I think cairo was a bad move, however that's just my opinion...


regards
--
Charlotte Maia
http://sites.google.com/site/maiagx/home

__
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] Bug in R evaluating a huge instruction (PR#14096)

2009-12-01 Thread Duncan Murdoch 

On 01/12/2009 12:50 AM, Jean Couteau wrote:

Thanks for your time Duncan,

I join here the instruction that is not correct, hoping that might help 
you. The file is encoded in utf-8 so you should not have any problem 
reading it.


I doubt to that it is an R bug too, but with all my tests i am less and 
less sure of that.


I have no problem sourcing that file, but I do get an error if I try to 
cut and paste it, because it's a single line of 4890 characters, and 
that's too long.  So this is an R limitation, but it's one with an easy 
workaround:  just add some line breaks into your source.


Duncan Murdoch




Best regards,
Jean Couteau
Your message has encoding problems, so it's not readable.  Could you 
put the code online somewhere where we could download it in its 
original form?  I doubt if this is an R bug, but I can't point out the 
problem in your code (or confirm that it really is an R bug) without 
an undamaged copy of the code.


Duncan Murdoch







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

Re: [Rd] [R] How to quit unwanted execution immediately?

2009-12-01 Thread Peng Yu 
The delay that I observe is when I type ctrl+C after I str() a long
list. Since str() comes from the core R installation, maybe it should
be improved?

> R can or cannot response immediately depending on the underlying C sources.
> If the underlying source code is written carefully enough, there are more or
> less regular checks for events such as this one.
> If you are using some contributed package, it may be an issue in this
> package's source code.
>
> Best wishes,
> Uwe Ligges
>
>
>
>
> Peng Yu wrote:
>>
>> Occasionally, I start a command (taking long time to finish) that I
>> did not really want to start. I type 'ctrl+C' to try to quit the
>> execution. However, R does not quit the execution of the command
>> immediately. I'm wondering if R could response to ctrl+C immediately.
>>
>> __
>> r-h...@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>

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

Re: [Rd] p-generalized normal distribution

2009-12-01 Thread Steve Kalke 

Ben Bolker schrieb:

Steve Kalke  uni-rostock.de> writes:

  
I would like to know if there is an R-package available for 
computing the density, distribution function,
quantiles and random 
numbers of the p-generalized normal distribution or 
if somebody is already working on it.



  I haven't been able to find out what the p-generalized normal
distribution is: the only paper I can find is

Sinz, F., and M. Bethge$. 2009. Characterization of the p-generalized 
normal distribution. Journal of Multivariate Analysis 100:817-820. 
doi: 10.1016/j.jmva.2008.07.006.


and I don't have access to it at the moment (although it does
at least hint that the required distribution is multivariate;
maybe p-dimensional?).  


 Is it the same as this?

Goodman, I. R., and S. Kotz. 1973. Multivariate θ-generalized normal
distributions. Journal of Multivariate Analysis 3:204-219. doi:
10.1016/0047-259X(73)90023-7.

  Where can we find a description?

  (Short answer: as far as I can tell, it doesn't exist in
R, but it would be good to have more information ...)

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


The p-generalized normal distribution was introduced in M.T. Subbotin's 
"On the law of frequency of errors" (1923), later studied in e.g. 
"Distributions in Statistics-Continous Univariate Distributions-2" from 
Johnson and Kotz (1970) or in "Continous l_n,p-symmetric distributions" 
from W.-D. Richter (2009), Lithuanian Math. J. 49.


A vector X=(X_1,...,X_n) is said to be p-generalized nomal distributed, 
if it's density function satisfies the reprensentation  f(x)=C^n * exp[-( 
|x_1|^p+...+|x_n|^p ) / p ] with C=p^(1-1/p)/(2*GAMMA(1/p)).


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

Re: [Rd] raster support in graphics devices

2009-12-01 Thread baptiste auguie 
Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf output is so much better in every way!

Incidentally, I ran into a segfault with grid.cap on the quartz
device, but maybe it's normal at this stage.

This works fine:

library(grid)
x11()
grid.text("test")
cap <- grid.cap()

This doesn't:

library(grid)
quartz()
grid.text("test")
cap <- grid.cap()

 *** caught segfault ***
address 0x18330001, cause 'memory not mapped'

Traceback:
 1: .Call(fnname, ..., PACKAGE = "grid")
 2: grid.Call("L_cap")
 3: grid.cap()

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

[R.app GUI 1.30 (5527) i386-apple-darwin9.8.0]

> sessionInfo()
R version 2.11.0 Under development (unstable) (2009-11-30 r50622)
i386-apple-darwin9.8.0

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

Best regards,

baptiste

2009/12/1 Paul Murrell :
> Hi
>
> This is for developers of extension packages that provide extra *graphics
> devices* for R.
>
> In the *development* version of R, support has been added to the graphics
> engine for sending raster images (bitmaps) to a graphics device.  This
> consists mainly of two new device functions:  dev_Raster() and dev_Cap().
>
> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a
> marker of this change.
>
> This means that, at a minimum, all graphics devices should be updated to
> provide dummy implementations of these new functions that just say the
> feature is not yet implemented (see for example the PicTeX and XFig devices
> in the 'grDevices' package).
>
> A full implementation of dev_Raster() should be able to draw a raster image
> (provided as an array of 32-bit R colors) at any size, possibly (bilinear)
> interpolated (otherwise nearest-neighbour), at any orientation, and with a
> per-pixel alpha channel.  Where these are not natively supported by a
> device, the graphics engine provides some routines for scaling and rotating
> raster images (see for example the X11 device).  The dev_Cap() function
> should return a representation of a raster image captured from the current
> device.  This will only make sense for some devices (see for example the
> Cairo device in the 'grDevices' package).
>
> A little more information and a couple of small examples are provided at
> http://developer.r-project.org/Raster/raster-RFC.html
>
> Paul
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> __
> 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] barplot: auto sizing for ylim variable

2009-12-01 Thread violet lock 
Dear R-Devel,
I am trying to create a barplot for a large dataset (about 1500 entries)
 and was wondering if there was away to do auto sizing for the y-axis of a
horizontal bar plot such that the data displays in a readable format and can
be scrolled or paged through?  I know I could use a control structure to
loop through the data instead, but as I know SAS has something does this
automatically I thought R might as well.

Thanks,
VL

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

2009-12-01 Thread Paul Murrell 

Hi


baptiste auguie wrote:

Very nice, thank you for this great addition to R graphics! I can't
wait to see lattice and ggplot2 functions that use rasterGrob to
display images. The pdf output is so much better in every way!

Incidentally, I ran into a segfault with grid.cap on the quartz
device, but maybe it's normal at this stage.



This may be due to the fact that I tested the changes on Mac OS X 10.6 
(looks like you have 10.5 ?), plus the fact that I am feeling my way a 
bit on the Mac.  I have access to a 10.4 machine so I will try to take a 
look there.  Thanks for the report.


Paul



This works fine:

library(grid)
x11()
grid.text("test")
cap <- grid.cap()

This doesn't:

library(grid)
quartz()
grid.text("test")
cap <- grid.cap()

 *** caught segfault ***
address 0x18330001, cause 'memory not mapped'

Traceback:
 1: .Call(fnname, ..., PACKAGE = "grid")
 2: grid.Call("L_cap")
 3: grid.cap()

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

[R.app GUI 1.30 (5527) i386-apple-darwin9.8.0]


sessionInfo()

R version 2.11.0 Under development (unstable) (2009-11-30 r50622)
i386-apple-darwin9.8.0

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

Best regards,

baptiste

2009/12/1 Paul Murrell :

Hi

This is for developers of extension packages that provide extra *graphics
devices* for R.

In the *development* version of R, support has been added to the graphics
engine for sending raster images (bitmaps) to a graphics device.  This
consists mainly of two new device functions:  dev_Raster() and dev_Cap().

The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a
marker of this change.

This means that, at a minimum, all graphics devices should be updated to
provide dummy implementations of these new functions that just say the
feature is not yet implemented (see for example the PicTeX and XFig devices
in the 'grDevices' package).

A full implementation of dev_Raster() should be able to draw a raster image
(provided as an array of 32-bit R colors) at any size, possibly (bilinear)
interpolated (otherwise nearest-neighbour), at any orientation, and with a
per-pixel alpha channel.  Where these are not natively supported by a
device, the graphics engine provides some routines for scaling and rotating
raster images (see for example the X11 device).  The dev_Cap() function
should return a representation of a raster image captured from the current
device.  This will only make sense for some devices (see for example the
Cairo device in the 'grDevices' package).

A little more information and a couple of small examples are provided at
http://developer.r-project.org/Raster/raster-RFC.html

Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

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



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

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

Re: [Rd] raster support in graphics devices

2009-12-01 Thread Charlotte Maia 
On 12/2/09, Simon Urbanek  wrote:
> Charlotte,
>
>
> I would like to point out that implicitly you have been already using raster
> graphics all the time in very inefficient form in heatmaps etc. The point
> here is not really about added functionality for the user but efficiency,
> because now we can finally use efficient encoding of heatmaps, matrix
> visualizations, overlay data over satellite images etc. Although all this
> was always possible in R, it was very inefficient and caused unwanted side
> effects (see the constant anti-aliasing discussions).
>
> Cheers,
> Simon

I might be unpopular for saying this, heatmaps are horrible things.
The first time I created a heatmap, I thought this is pretty, I've
since learnt better.

If I wasn't unpopular for saying that, this will certainly make me
unpopular, what is with that image at the top of JSS? There is bad
typesetting, and then there is bad typesetting...

I think many users are getting caught up in creating pretty images,
and the impression I'm getting is that various software (not just R)
is making this easier.
Whenever I'm reading an article and I see a heatmap, I say a few curse
words and then just settle for reading the abstract, and maybe the
first page of the introduction, if I've had a good day...

There are still substantial problems with R's vector graphics,
creating curves and circles for example. On evince, my plots just look
like a bunch of "q"s (not sure whether it's evince's fault or R's
fault). Plus including figures in sweave is relatively difficult in my
opinion.

Regarding Martins comments on changing the graphics device, I have
noticed some errors in doing so, hence have been (reluctantly)
sticking to cairo. What that saying, if you can't beat them, joint
them... or something like that...

Then there's all those people (have no idea if this is correct or not)
that say creating plots in SAS and Matlab is faster than R.

Overall, I think there is substantial room for improvement both in the
use and implementation of vector graphics, especially static 2D vector
graphics, however trends for implementing  interactive graphics, 3d
graphics, and raster images seem to be getting too much precedence.

In regards to Simon's comments, if we are going to focus on
efficiency, shouldn't we make the useful things efficient first, and
not gett too distracted.

I don't know anything about matrix visualisation, however I'm
sceptical that it is a good idea to take a giant matrix, and map one
element to one pixel, say with colour indexing (essentially just
another heatmap).

Noting my opinions here are in regards to the entire R community
(really the entire statistical community), not just the original post.


regards
-- 
Charlotte Maia
http://sites.google.com/site/maiagx/home

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

Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Guillaume Yziquel 

Simon Urbanek a écrit :


You just pass it as value of the call. I suspect the reason it doesn't 
work is in your code, not in the facility (note that the link above is 
useless since the construction is mystery - if you were constructing it 
right, it would work ;)).


Small example:

SEXP myEval(SEXP FN, SEXP first_arg) {
  return eval(LCONS(FN, CONS(first_arg, R_NilValue)), R_GlobalEnv);
}

... or reading R-ext:

"There are a series of small macros/functions to help construct 
pairlists and language objects (whose internal structures just differ by 
SEXPTYPE. Function CONS(u, v) is the basic building block: is constructs 
a pairlist from u followed by v (which is a pairlist or R_NilValue). 
LCONS is a variant that constructs a language object. Functions list1 to 
list4 construct a pairlist from one to four items, andlang1 to lang4 do 
the same for a language object (a function to call plus zero to three 
arguments). Function elt and lastElt find the ith element and the last 
element of a pairlist, and nthcdr returns a pointer to the nth position 
in the pairlist (whose CAR is the nth item)."


Reading R-exts,

-1- I believe it would be a good idea to put an example with CONS and 
LCONS in section 5.11.


-2- Building a LANGSXP list with tags from arguments needs invocations 
of CONS LCONS SET_TAG and install. While this is not exactly to my 
taste, using install is really not to my taste since it checks the 
symbol table and eventually creates a symbol. Isn't there a way to 
create a tag without using install over and over? A macro that simply 
sets the tag to whatever CHARSXP might be useful?


--
 Guillaume Yziquel
http://yziquel.homelinux.org/

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

Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Simon Urbanek 

On Dec 1, 2009, at 8:32 PM, Guillaume Yziquel wrote:

> Simon Urbanek a écrit :
>> You just pass it as value of the call. I suspect the reason it doesn't work 
>> is in your code, not in the facility (note that the link above is useless 
>> since the construction is mystery - if you were constructing it right, it 
>> would work ;)).
>> Small example:
>> SEXP myEval(SEXP FN, SEXP first_arg) {
>>  return eval(LCONS(FN, CONS(first_arg, R_NilValue)), R_GlobalEnv);
>> }
>> ... or reading R-ext:
>> "There are a series of small macros/functions to help construct pairlists 
>> and language objects (whose internal structures just differ by SEXPTYPE. 
>> Function CONS(u, v) is the basic building block: is constructs a pairlist 
>> from u followed by v (which is a pairlist or R_NilValue). LCONS is a variant 
>> that constructs a language object. Functions list1 to list4 construct a 
>> pairlist from one to four items, andlang1 to lang4 do the same for a 
>> language object (a function to call plus zero to three arguments). Function 
>> elt and lastElt find the ith element and the last element of a pairlist, and 
>> nthcdr returns a pointer to the nth position in the pairlist (whose CAR is 
>> the nth item)."
> 
> Reading R-exts,
> 
> -1- I believe it would be a good idea to put an example with CONS and LCONS 
> in section 5.11.
> 
> -2- Building a LANGSXP list with tags from arguments needs invocations of 
> CONS LCONS SET_TAG and install. While this is not exactly to my taste, using 
> install is really not to my taste since it checks the symbol table and 
> eventually creates a symbol. Isn't there a way to create a tag without using 
> install over and over? A macro that simply sets the tag to whatever CHARSXP 
> might be useful?
> 

No, because you cannot use CHARSXP as a TAG. TAGs are always symbols. 
Therefore, logically, you must register it first in (or obtain from) the symbol 
table using install.

Cheers,
Simon

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

Re: [Rd] PROTECT and OCaml GC.

2009-12-01 Thread Guillaume Yziquel 

Simon Urbanek a écrit :


No, because you cannot use CHARSXP as a TAG. TAGs are always symbols. 
Therefore, logically, you must register it first in (or obtain from) the symbol 
table using install.


OK. That's R side.

OCaml side, I need to have as little side-effects as possible. Symbol 
assignment is a side-effect.


Is there an API-compliant way to handle this, and make data structures 
as immutable as possible?


--
 Guillaume Yziquel
http://yziquel.homelinux.org/

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

[Rd] re: documentation omission in Extract.Rd?

2009-12-01 Thread Charlotte Maia 
Hi Tony,

I don't know the answer to your question. The base package in R is
constantly full of pleasant surprises.

However I would image that the Rd files you have mentioned are
sufficient examples of how to write documentation for extraction and
replacement functions.


kind regards
-- 
Charlotte Maia
http://sites.google.com/site/maiagx/home

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