Re: [R] [FORGED] Re: Block comment?

[Rolf Turner]

On 03/09/17 12:29, Duncan Murdoch wrote:


On 02/09/2017 6:57 PM, Rolf Turner wrote:

On 03/09/17 03:56, William Dunlap via R-help wrote:

Is the reason you want a block comment containing code (as opposed to
arbitrary text) that you want to be able to easily run the commented out
code?  If so the 'if()' construct has the advantage that you only 
need to

change code at the start of the comment, not at both ends.

The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you
would not even have to change code to re-enable the debugging code, just
call options(DEBUG_ISSUE_XYX=TRUE)).



(a) The foregoing is getting too subtle for my feeble brain.

(b) A fundamental problem with the

 if(FALSE) {
...
 }

paradigm is that the enclosed code must be syntactically valid, and
there are certainly situations in which one might wish to comment out
sections of code that are *not* syntactically valid.  E.g. one might
wish to comment out *part* of a piece of syntactically valid code for
the purpose of experimenting with an alternative approach.


If the code is not syntactically valid, why would you expect the block 
comment to be syntactically valid?


I thought I had made that clear.  One might wish to comment out a 
*piece* of syntactically valid code (with a view to replacing it).
The piece commented out might not be syntactically valid simply because 
it is *just a piece* and might thereby be incomplete.


The proposal at the start of this 
thread was that #{ would open the block and would be matched by }# to 
close the block.  What if the closing sequence occurred within the block 
unintentionally?  Then the poor feeble programmer would be even more 
confused.


Do not the same considerations essentially apply to the well established
/*  */ convention used in C?  Well maybe you simply *can't* get the 
"*/" string within a block of C code, but still 


If "#{}#" runs this risk, then some other construction which doesn't 
run the risk could be used.


I like the current rule: 


De gustibus non disputandum.

any line starting with # is a comment. 
(Actually the rule is a bit more subtle than that, but it's close.)
If I want to comment out a block, I can spend a long time typing # at 
the start of every line, or I can ask my editor to do it.  I don't need 
to worry if something in the block unintentionally closes it, because 
that's impossible.  If the first line is a comment, all the rest are too.


I don't follow the foregoing, but no matter.  I'm slow.

This issue is quite obviously No Big Deal.  Block comments are a 
convenience that it would be nice to have, but obviously one can live 
without them and not suffer unduly.


cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] [FORGED] Re: Block comment?

[Duncan Murdoch]

On 02/09/2017 6:57 PM, Rolf Turner wrote:

On 03/09/17 03:56, William Dunlap via R-help wrote:

Is the reason you want a block comment containing code (as opposed to
arbitrary text) that you want to be able to easily run the commented out
code?  If so the 'if()' construct has the advantage that you only need to
change code at the start of the comment, not at both ends.

The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you
would not even have to change code to re-enable the debugging code, just
call options(DEBUG_ISSUE_XYX=TRUE)).



(a) The foregoing is getting too subtle for my feeble brain.

(b) A fundamental problem with the

 if(FALSE) {
...
 }

paradigm is that the enclosed code must be syntactically valid, and
there are certainly situations in which one might wish to comment out
sections of code that are *not* syntactically valid.  E.g. one might
wish to comment out *part* of a piece of syntactically valid code for
the purpose of experimenting with an alternative approach.


If the code is not syntactically valid, why would you expect the block 
comment to be syntactically valid?  The proposal at the start of this 
thread was that #{ would open the block and would be matched by }# to 
close the block.  What if the closing sequence occurred within the block 
unintentionally?  Then the poor feeble programmer would be even more 
confused.


I like the current rule:  any line starting with # is a comment. 
(Actually the rule is a bit more subtle than that, but it's close.)
If I want to comment out a block, I can spend a long time typing # at 
the start of every line, or I can ask my editor to do it.  I don't need 
to worry if something in the block unintentionally closes it, because 
that's impossible.  If the first line is a comment, all the rest are too.


Duncan Murdoch

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] [FORGED] Re: Block comment?

[Rolf Turner]

On 03/09/17 03:56, William Dunlap via R-help wrote:

Is the reason you want a block comment containing code (as opposed to
arbitrary text) that you want to be able to easily run the commented out
code?  If so the 'if()' construct has the advantage that you only need to
change code at the start of the comment, not at both ends.

The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you
would not even have to change code to re-enable the debugging code, just
call options(DEBUG_ISSUE_XYX=TRUE)).



(a) The foregoing is getting too subtle for my feeble brain.

(b) A fundamental problem with the

   if(FALSE) {
  ...
   }

paradigm is that the enclosed code must be syntactically valid, and 
there are certainly situations in which one might wish to comment out 
sections of code that are *not* syntactically valid.  E.g. one might 
wish to comment out *part* of a piece of syntactically valid code for 
the purpose of experimenting with an alternative approach.


cheers,

Rolf

--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276


On Sat, Sep 2, 2017 at 7:54 AM, Suzen, Mehmet  wrote:


AFAIK block comment is not possible
it needs to be implemented in R interpreter and defined in the
parser.'If' solution is not elegant.

On 2 September 2017 at 14:09, Uwe Ligges
 wrote:



On 02.09.2017 11:40, Christian wrote:


I consider it quite worth while to introduce into R syntax a nestable
block comment like

#{

}#



if(FALSE){

}

Best,
Uwe Ligges



It would make documentation more easily manageable and lucid.
Is there considerable need for this.

Please, comment on this.
How about R core?

Christian



__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.



[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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] problem in testing data with e1071 package (SVM Multiclass)

[stefania.pec...@univ-ubs.fr]

Hello all,

this is the first time I'm using R and e1071 package and SVM multiclass 
(and I'm not a statistician)! I'm very confused, then. The goal is: I 
have a sentence with sunny; it will be classified as "yes" sentence; I 
have a sentence with cloud, it will be classified as "maybe"; I have a 
sentence with rainy il will be classified as "no".

The true goal is to do some text classification to apply then for my 
research.

I have two files:

  * train.csv: a file where there are two columns/Variables one is the
data, the other is the label

Example:

|V1 V2 1sunny yes 2sunny sunny yes 3sunny rainy sunny yes 4sunny cloud 
sunny yes 5rainy no6rainy rainy no7rainy sunny rainy no8rainy cloud 
rainy no9cloud maybe 10cloud cloud maybe 11cloud rainy cloud maybe 
12cloud sunny cloud maybe|

  * test.csv: in this file there are the new data to be classified and
it is in one column/variable.

Example:

|V1 1sunny 2rainy 3hello 4cloud 5a 6b 7cloud 8d 9e 10f 11g 12hello|

Following the examples from the iris dataset 
(https://cran.r-project.org/web/packages/e1071/e1071.pdfandhttp://rischanlab.github.io/SVM.html)
 
I created my model and then test the training data in this way:

|>library(e1071)
>train <-read.csv(file="./train.csv",sep =";",header =FALSE)
 >test <-read.csv(file="./test.csv",sep =";",header =FALSE)>attach(train)
>x <-subset(train,select=-V2)
>y <-V2 >model <-svm(V2 ~.,data =train,probability=TRUE)
>summary(model)
Call:svm(formula =V2 ~.,data =train,probability 
=TRUE)Parameters:SVM-Type:C-classification SVM-Kernel:radial 
cost:1gamma:0.0833Numberof SupportVectors:12(444)Numberof 
Classes:3Levels:maybe noyes
>pred <-predict(model,x)
 >system.time(pred <-predict(model,x))
user system elapsed 000
 >table(pred,y)y
|

|pred maybe noyes maybe 400no040yes 004>pred 123456789101112yes yes yes 
yes nonononomaybe maybe maybe maybe Levels:maybe noyes|


||

I think it's ok until now. Now the question is: what about the test 
data? I didn't find anything for the test data. Then, I thought that 
maybe I should test the model with the test data. And I did this:

| >test V1 1sunny 2rainy 3hello 4cloud 5a 6b 7cloud 8d 9e 10f 11g 12hello 
 >z <-subset(test,select=V1)>pred 
<-predict(model,z)Errorinpredict.svm(model,z):test data does notmatch 
model !|

What is wrong here? Can you please explain me how can I test new data 
using the old train model? For two days I asked everywhere and saw many 
websites but didn't find a solution and it's very complicated because I 
think that the logic behind the code is ok, but something is missin in 
my way to express it using R.

Thank you for your help

||


[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Precision error in time index of ts objects

[Achim Zeileis]

On Sat, 2 Sep 2017, Andrea Altomani wrote:


Thanks for the very detailed explanation.
I did not create the series using structure(), that was the result of dump()
on an intermediate object created within tsdisagg::ta(),


There is no tsdisagg package on CRAN, just tsdisagg2. But this does not 
have a function ta(). So I guess it's tempdisagg you are using?


which is where I found the error in the first place. ta() indeed 
manipulates .Tsp directly, rather than using ts. I guess this is a bug 
in tsdisagg then.


I just grabbed the latest version of tempdisagg from CRAN and this does 
not seem to have ".Tsp" anywhere in the code. It employs ts() in a couple 
of places so I'm not sure which part of the code you are referring to 
exactly.



On Sat, Sep 2, 2017 at 12:31 AM Achim Zeileis 
wrote:
  On Fri, 1 Sep 2017, Andrea Altomani wrote:

  > I should have formulated my question in a more specific way.
  >
  > 1. I suspect this is a floating point precision issue. I am
  not very
  > knowledgeable about R internals, can someone else confirm it?

  Yes. If you represent a series with increment 1/12 it depends on
  how you
  do it. As a simple example consider the following two
  descriptions of the
  same time point:

  2 - 1/12
  ## [1] 1.916667

  1 + 11/12
  ## [1] 1.916667

  However, both are not identical:

  (2 - 1/12) == (1 + 11/12)
  ## [1] FALSE

  The difference is just the .Machine$double.eps:

  (2 - 1/12) - (1 + 11/12)
  ## [1] 2.220446e-16

  > 2. Should this be considered a bug or not, because it is "just
  a
  > precision issue"? Should I report it?

  I don't think it is a bug because of the (non-standard) way how
  you
  created the time series.

  > 3. How can it happen? From a quick review of ts.R, it looks
  like the values
  > of the time index are never modified, but only possibly
  removed. In my case:
  >   - x and y have the same index.
  >   - the subtraction operator recognizes this, and create a new
  ts with one
  > entry
  >   - the result of the subtraction has an index which is
  different from the
  > input.
  >  This is very surprising to me, and I am curious to understand
  the problem.

  The object 'x' and hence the object 'y' have the same time
  index. But in
  'z' a new time index is created which is subtly different from
  that of
  'x'. The reason for this is that R doesn't expect an object like
  'x' to
  exist.

  You should create a "ts" object with ts(), e.g.,

  x <- ts(2017, start = c(2017, 6), freqency = 12)

  But you created something close to the internal
  representation...but not
  close enough:

  y <- structure(2017, .Tsp = c(2017.416667, 2017.416667, 12),
  class = "ts")

  The print functions prints both print(x) and print(y) as

         Jun
  2017 2017

  However, aligning the two time indexes in x - y or
  ts.intersect(x, y) does
  not work...because they are not the same

  as.numeric(time(x)) - as.numeric(time(y))
  ## [1] -3.32e-07

  The "ts" code tries to avoid these situations by making many
  time index
  comparisons only up to a precision of getOption("ts.eps") (1e-5
  by
  default) but this is not used everywhere. See ?options:

       'ts.eps': the relative tolerance for certain time series
  ('ts')
             computations.  Default '1e-05'.

  Of course, you could ask for this being used in more places,
  e.g., in
  stats:::.cbind.ts() where (st > en) is used rather than ((st -
  en) >
  getOption("ts.eps")). But it's probably safer to just use ts()
  rather than
  structure(). Or if you use the latter make sure that you do at a
  high
  enough precision.

  hth,
  Z


  > On Fri, Sep 1, 2017 at 5:53 PM Jeff Newmiller
  
  > wrote:
  >
  >> You already know the answer. Why ask?
  >> --
  >> Sent from my phone. Please excuse my brevity.
  >>
  >> On September 1, 2017 7:23:24 AM PDT, Andrea Altomani <
  >> altomani.and...@gmail.com> wrote:
  >>> I have a time series x, and two other series obtained from
  it:
  >>>
  >>> x <- structure(2017, .Tsp = c(2017.417,
  2017.417, 12),
  >>> class = "ts")
  >>> y <- floor(x)
  >>> z <- x-y
  >>>
  >>> I would expect the three series to have exactly the same
  index.
  >>> However I get the following
  >>>
   time(x)-time(y)
  >>>     Jun
  >>> 2017   0
  >>>
  >>> as expected, but
  >>>
   time(x)-time(z)
  >>> integer(0)
  >>> Warning message:
  >>> In .cbind.ts(list(e1, e2), c(deparse(substitute(e1))[1L],
  >>> deparse(substitute(e2))[1L]),  :
  >>>  

Re: [R] Strange lazy evaluation of default arguments

[Bert Gunter]

This is exactly as expected. See section 4.3.3 of the R Language definition
or google around on "R Lazy Evaluation" for details.

You should not "expect" R's semantics to be the same as other languages
with which you may be familiar. Spending time with a good tutorial or two
should help you sort out points of similarity and differences.

Cheers,
Bert



Bert Gunter

"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )

On Sat, Sep 2, 2017 at 10:22 AM, Matthias Gondan 
wrote:

> Dear R developers,
>
> sessionInfo() below
>
> Please have a look at the following two versions of the same function:
>
> 1. Intended behavior:
>
> > Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
> + {
> +   print(c(u, l, mu)) # here, l is set to u’s value
> +   u = u/sqrt(sigma2)
> +   l = l/sqrt(sigma2)
> +   mu = mu/sqrt(sigma2)
> +   print(c(u, l, mu))
> + }
> >
> > Su1()
> [1] 100.00 100.00   0.53
> [1] 23.2558140 23.2558140  0.1232558
>
> In the first version, both u and l are correctly divided by 4.3.
>
> 2. Strange behavior:
>
> > Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
> + {
> +   # print(c(u, l, mu))
> +   u = u/sqrt(sigma2)
> +   l = l/sqrt(sigma2) # here, l is set to u’s value
> +   mu = mu/sqrt(sigma2)
> +   print(c(u, l, mu))
> + }
> >
> > Su2()
> [1] 23.2558140  5.4083288  0.1232558
> In the second version, the print function is commented out, so the
> variable u is
> copied to l (lowercase L) at a later place, and L is divided twice by 4.3.
>
> Is this behavior intended? It seems strange that the result depends on a
> debugging message.
>
> Best wishes,
>
> Matthias
>
>
> > sessionInfo()
> R version 3.4.1 (2017-06-30)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows >= 8 x64 (build 9200)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
> LC_MONETARY=German_Germany.1252
> [4] LC_NUMERIC=CLC_TIME=German_Germany.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.1 tools_3.4.1
>
>
> [[alternative HTML version deleted]]
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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.

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R-es] Consejo

[Carlos Ortega]

Basados en R hay alguno:

https://www.amazon.es/Complex-Surveys-Analysis-Survey-Methodology/dp/0470284307/ref=sr_1_2?ie=UTF8=1504376183=8-2=survey+with+R

Mira en cualquier caso las referencias, bibliografía, artículos que suelen
aparecer en la ayuda de cada paquete.

También esta referencia te puede venir muy bien:
http://blog.revolutionanalytics.com/2013/01/flowchart-how-to-learn-survey-analysis-with-r.html

Saludos,
Carlos Ortega
www.qualityexcellence.es

El 2 de septiembre de 2017, 19:19, Antonio Rodriguez Andres <
antoniorodriguezandre...@gmail.com> escribió:

> Muchas gracias, me recomienda algunos libros para comenzar.
>
> Saludos
>
> El 2/09/2017 3:16 p. m., "Javier Marcuzzi"  com>
> escribió:
>
> > Estimado Antonio Rodriguez Andres
> >
> >
> >
> > Comienza por donde quieras, lee un libro general, luego otro sobre un
> tema
> > específico, realiza muchos ejercicios, y luego intente manejar muchos
> > datos, de lo contrario quedará enredado con los datos propios y las
> > distintas alternativas que tiene R para el mismo fin. Estudie todo lo que
> > quiera, pero yo en lo personal una gran cantidad de datos no se la doy a
> > una persona en sus inicios, no por incapacidad de esta, sino por el
> peligro
> > de una confusión en el ordenamiento y codificación, en otras palabras,
> hay
> > que asegurar los cimientos del edificio, luego discutir el color de la
> > ventana.
> >
> >
> >
> > Javier Rubén Marcuzzi
> >
> >
> >
> > *De: *Antonio Rodriguez Andres 
> > *Enviado: *viernes, 1 de septiembre de 2017 5:28
> > *Para: *r-help-es 
> > *Asunto: *[R-es] Consejo
> >
> >
> >
> > Estimados miembros de la comunidad de R
> >
> >
> >
> > Me gustaria conocer dado que estoy trabajando con datos del World Values
> >
> > Survey, y tengo que recodificar variables y manipularlas,
> >
> > por donde podria empezar a estudiar el uso de R en grandes surveys. Que
> >
> > podria comenzar a la leer.
> >
> > Su respuesta sera bienvenida
> >
> >
> >
> > saludos
> >
> >
> >
> > Antonio
> >
> >
> >
> > --
> >
> >
> >
> > Member, Editorial Committee, *The Economic and Labour Relations Review*
> (a
> >
> > SAGE journal)
> >
> >
> >
> > http://elr.sagepub.com/
> >
> >
> >
> > Member, Editorial Committee, African Journal of Economic and Management
> >
> > Studies
> >
> >
> >
> > http://emeraldgrouppublishing.com/products/journals/
> > editorial_team.htm?id=ajems
> >
> >
> >
> > https://www.researchgate.net/profile/Antonio_Andres (Research Gate
> > profile)
> >
> >
> >
> > [[alternative HTML version deleted]]
> >
> >
> >
> > ___
> >
> > R-help-es mailing list
> >
> > R-help-es@r-project.org
> >
> > https://stat.ethz.ch/mailman/listinfo/r-help-es
> >
> >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-help-es mailing list
> R-help-es@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>



-- 
Saludos,
Carlos Ortega
www.qualityexcellence.es

[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es

Re: [R] Strange lazy evaluation of default arguments

[Jeff Newmiller]

Yes, this is intended behavior, and it has everything to do with where the 
parameters are first referenced and nothing to do with debugging. 
-- 
Sent from my phone. Please excuse my brevity.

On September 2, 2017 10:22:22 AM PDT, Matthias Gondan  
wrote:
>Dear R developers,
>
>sessionInfo() below
>
>Please have a look at the following two versions of the same function:
>
>1. Intended behavior:
>
>> Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
>+ {
>+   print(c(u, l, mu)) # here, l is set to u’s value
>+   u = u/sqrt(sigma2)
>+   l = l/sqrt(sigma2)
>+   mu = mu/sqrt(sigma2)
>+   print(c(u, l, mu))
>+ }
>> 
>> Su1()
>[1] 100.00 100.00   0.53
>[1] 23.2558140 23.2558140  0.1232558
>
>In the first version, both u and l are correctly divided by 4.3.
>
>2. Strange behavior:
>
>> Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
>+ {
>+   # print(c(u, l, mu))
>+   u = u/sqrt(sigma2)
>+   l = l/sqrt(sigma2) # here, l is set to u’s value
>+   mu = mu/sqrt(sigma2)
>+   print(c(u, l, mu))
>+ }
>> 
>> Su2()
>[1] 23.2558140  5.4083288  0.1232558>In the second version, the print
>function is commented out, so the variable u is 
>copied to l (lowercase L) at a later place, and L is divided twice by
>4.3.
>
>Is this behavior intended? It seems strange that the result depends on
>a debugging message.
>
>Best wishes,
>
>Matthias sessionInfo()
>R version 3.4.1 (2017-06-30)
>Platform: x86_64-w64-mingw32/x64 (64-bit)
>Running under: Windows >= 8 x64 (build 9200)
>
>Matrix products: default
>
>locale:
>[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252   
>LC_MONETARY=German_Germany.1252
>[4] LC_NUMERIC=CLC_TIME=German_Germany.1252
>
>attached base packages:
>[1] stats graphics  grDevices utils datasets  methods   base   
> 
>
>loaded via a namespace (and not attached):
>[1] compiler_3.4.1 tools_3.4.1   
>
>
>   [[alternative HTML version deleted]]
>
>__
>R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Strange lazy evaluation of default arguments

[Matthias Gondan]

Dear Bill,

All makes perfect sense (including the late evaluation). I actually discovered 
the problem by looking at old code which used your proposed solution. Still I 
find it strange (and, hnestly, I don’t like R’s behavior in this respect), and 
I am wondering why u is not being copied to L just before u is assigned a new 
value. Of course, this would require the R interpreter to track all these 
dependencies in both ways incl. more complicated ones in which L might depend 
on more than just u.

In the future, I’ll avoid dependencies between parameters.

Su4 <- function(u=100, l=100, mu=0.53, sigma2=4.3^2) # instead of l=u

And maybe also „in-place“ changes of values…

Best regards,

Matthias

Von: William Dunlap
Gesendet: Samstag, 2. September 2017 19:41
An: Rui Barradas
Cc: Matthias Gondan; r-help@r-project.org
Betreff: Re: [R] Strange lazy evaluation of default arguments

Another way to avoid the problem is to not redefine variables that are 
arguments.  E.g.,

> Su3 <- function(u=100, l=u, mu=0.53, sigma2=4.3^2, verbose)
  {
    if (verbose) {
      print(c(u, l, mu))
    }
    uNormalized <- u/sqrt(sigma2)
    lNormalized <- l/sqrt(sigma2)
    muNormalized <- mu/sqrt(sigma2)
    c(uNormalized, lNormalized, muNormalized)
  }
> Su3(verbose=TRUE)
[1] 100.00 100.00   0.53
[1] 23.2558140 23.2558140  0.1232558
> Su3(verbose=FALSE)
[1] 23.2558140 23.2558140  0.1232558

Not redefining variables at all makes debugging easier, although it may waste 
space.


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Sat, Sep 2, 2017 at 10:33 AM,  wrote:
Hello,

One way of preventing that is to use ?force.
Just put

   force(l)

right after the commented out print and before you change 'u'.

Hope this helps,

Rui Barradas



Citando Matthias Gondan :

Dear R developers,

sessionInfo() below

Please have a look at the following two versions of the same function:

1. Intended behavior:
Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
+ {
+   print(c(u, l, mu)) # here, l is set to u’s value
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2)
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }

Su1()
[1] 100.00 100.00   0.53
[1] 23.2558140 23.2558140  0.1232558

In the first version, both u and l are correctly divided by 4.3.

2. Strange behavior:
Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
+ {
+   # print(c(u, l, mu))
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2) # here, l is set to u’s value
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }

Su2()
[1] 23.2558140  5.4083288  0.1232558
In the second version, the print
function is commented out, so the variable u is
copied to l (lowercase L) at a later place, and L is divided twice by 4.3.

Is this behavior intended? It seems strange that the result depends on a 
debugging message.

Best wishes,

Matthias

sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252    
LC_MONETARY=German_Germany.1252
[4] LC_NUMERIC=C                    LC_TIME=German_Germany.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.4.1 tools_3.4.1


        [[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.



[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Strange lazy evaluation of default arguments

[William Dunlap via R-help]

Another way to avoid the problem is to not redefine variables that are
arguments.  E.g.,

> Su3 <- function(u=100, l=u, mu=0.53, sigma2=4.3^2, verbose)
  {
if (verbose) {
  print(c(u, l, mu))
}
uNormalized <- u/sqrt(sigma2)
lNormalized <- l/sqrt(sigma2)
muNormalized <- mu/sqrt(sigma2)
c(uNormalized, lNormalized, muNormalized)
  }
> Su3(verbose=TRUE)
[1] 100.00 100.00   0.53
[1] 23.2558140 23.2558140  0.1232558
> Su3(verbose=FALSE)
[1] 23.2558140 23.2558140  0.1232558

Not redefining variables at all makes debugging easier, although it may
waste space.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Sat, Sep 2, 2017 at 10:33 AM,  wrote:

> Hello,
>
> One way of preventing that is to use ?force.
> Just put
>
>force(l)
>
> right after the commented out print and before you change 'u'.
>
> Hope this helps,
>
> Rui Barradas
>
>
>
> Citando Matthias Gondan :
>
>
> Dear R developers,
>>
>> sessionInfo() below
>>
>> Please have a look at the following two versions of the same function:
>>
>> 1. Intended behavior:
>>
>> Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
>>>
>> + {
>> +   print(c(u, l, mu)) # here, l is set to u’s value
>> +   u = u/sqrt(sigma2)
>> +   l = l/sqrt(sigma2)
>> +   mu = mu/sqrt(sigma2)
>> +   print(c(u, l, mu))
>> + }
>>
>>>
>>> Su1()
>>>
>> [1] 100.00 100.00   0.53
>> [1] 23.2558140 23.2558140  0.1232558
>>
>> In the first version, both u and l are correctly divided by 4.3.
>>
>> 2. Strange behavior:
>>
>> Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
>>>
>> + {
>> +   # print(c(u, l, mu))
>> +   u = u/sqrt(sigma2)
>> +   l = l/sqrt(sigma2) # here, l is set to u’s value
>> +   mu = mu/sqrt(sigma2)
>> +   print(c(u, l, mu))
>> + }
>>
>>>
>>> Su2()
>>>
>> [1] 23.2558140  5.4083288  0.1232558
>>
> In the second version, the print
>
>> function is commented out, so the variable u is
>> copied to l (lowercase L) at a later place, and L is divided twice by 4.3.
>>
>> Is this behavior intended? It seems strange that the result depends on a
>> debugging message.
>>
>> Best wishes,
>>
>> Matthias
>>
>
>
> sessionInfo()
>> R version 3.4.1 (2017-06-30)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows >= 8 x64 (build 9200)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
>> LC_MONETARY=German_Germany.1252
>> [4] LC_NUMERIC=CLC_TIME=German_Germany.1252
>>
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.4.1 tools_3.4.1
>>
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posti
>> ng-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posti
> ng-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Strange lazy evaluation of default arguments

[ruipbarradas]

Hello,

One way of preventing that is to use ?force.
Just put

   force(l)

right after the commented out print and before you change 'u'.

Hope this helps,

Rui Barradas



Citando Matthias Gondan :


Dear R developers,

sessionInfo() below

Please have a look at the following two versions of the same function:

1. Intended behavior:


Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)

+ {
+   print(c(u, l, mu)) # here, l is set to u’s value
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2)
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }


Su1()

[1] 100.00 100.00   0.53
[1] 23.2558140 23.2558140  0.1232558

In the first version, both u and l are correctly divided by 4.3.

2. Strange behavior:


Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)

+ {
+   # print(c(u, l, mu))
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2) # here, l is set to u’s value
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }


Su2()

[1] 23.2558140  5.4083288  0.1232558

In the second version, the print

function is commented out, so the variable u is
copied to l (lowercase L) at a later place, and L is divided twice by 4.3.

Is this behavior intended? It seems strange that the result depends  
on a debugging message.


Best wishes,

Matthias




sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252 
LC_MONETARY=German_Germany.1252

[4] LC_NUMERIC=CLC_TIME=German_Germany.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.4.1 tools_3.4.1


[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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] Strange lazy evaluation of default arguments

[Matthias Gondan]

Dear R developers,

sessionInfo() below

Please have a look at the following two versions of the same function:

1. Intended behavior:

> Su1 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
+ {
+   print(c(u, l, mu)) # here, l is set to u’s value
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2)
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }
> 
> Su1()
[1] 100.00 100.00   0.53
[1] 23.2558140 23.2558140  0.1232558

In the first version, both u and l are correctly divided by 4.3.

2. Strange behavior:

> Su2 = function(u=100, l=u, mu=0.53, sigma2=4.3^2)
+ {
+   # print(c(u, l, mu))
+   u = u/sqrt(sigma2)
+   l = l/sqrt(sigma2) # here, l is set to u’s value
+   mu = mu/sqrt(sigma2)
+   print(c(u, l, mu))
+ }
> 
> Su2()
[1] 23.2558140  5.4083288  0.1232558
In the second version, the print function is commented out, so the variable u 
is 
copied to l (lowercase L) at a later place, and L is divided twice by 4.3.

Is this behavior intended? It seems strange that the result depends on a 
debugging message.

Best wishes,

Matthias


> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252
LC_MONETARY=German_Germany.1252
[4] LC_NUMERIC=CLC_TIME=German_Germany.1252

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

loaded via a namespace (and not attached):
[1] compiler_3.4.1 tools_3.4.1   


[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R-es] Consejo

[Antonio Rodriguez Andres]

Muchas gracias, me recomienda algunos libros para comenzar.

Saludos

El 2/09/2017 3:16 p. m., "Javier Marcuzzi" 
escribió:

> Estimado Antonio Rodriguez Andres
>
>
>
> Comienza por donde quieras, lee un libro general, luego otro sobre un tema
> específico, realiza muchos ejercicios, y luego intente manejar muchos
> datos, de lo contrario quedará enredado con los datos propios y las
> distintas alternativas que tiene R para el mismo fin. Estudie todo lo que
> quiera, pero yo en lo personal una gran cantidad de datos no se la doy a
> una persona en sus inicios, no por incapacidad de esta, sino por el peligro
> de una confusión en el ordenamiento y codificación, en otras palabras, hay
> que asegurar los cimientos del edificio, luego discutir el color de la
> ventana.
>
>
>
> Javier Rubén Marcuzzi
>
>
>
> *De: *Antonio Rodriguez Andres 
> *Enviado: *viernes, 1 de septiembre de 2017 5:28
> *Para: *r-help-es 
> *Asunto: *[R-es] Consejo
>
>
>
> Estimados miembros de la comunidad de R
>
>
>
> Me gustaria conocer dado que estoy trabajando con datos del World Values
>
> Survey, y tengo que recodificar variables y manipularlas,
>
> por donde podria empezar a estudiar el uso de R en grandes surveys. Que
>
> podria comenzar a la leer.
>
> Su respuesta sera bienvenida
>
>
>
> saludos
>
>
>
> Antonio
>
>
>
> --
>
>
>
> Member, Editorial Committee, *The Economic and Labour Relations Review* (a
>
> SAGE journal)
>
>
>
> http://elr.sagepub.com/
>
>
>
> Member, Editorial Committee, African Journal of Economic and Management
>
> Studies
>
>
>
> http://emeraldgrouppublishing.com/products/journals/
> editorial_team.htm?id=ajems
>
>
>
> https://www.researchgate.net/profile/Antonio_Andres (Research Gate
> profile)
>
>
>
> [[alternative HTML version deleted]]
>
>
>
> ___
>
> R-help-es mailing list
>
> R-help-es@r-project.org
>
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>
>
>

[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es

Re: [R] Block comment?

[William Dunlap via R-help]

Is the reason you want a block comment containing code (as opposed to
arbitrary text) that you want to be able to easily run the commented out
code?  If so the 'if()' construct has the advantage that you only need to
change code at the start of the comment, not at both ends.

The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you
would not even have to change code to re-enable the debugging code, just
call options(DEBUG_ISSUE_XYX=TRUE)).


Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Sat, Sep 2, 2017 at 7:54 AM, Suzen, Mehmet  wrote:

> AFAIK block comment is not possible
> it needs to be implemented in R interpreter and defined in the
> parser.'If' solution is not elegant.
>
> On 2 September 2017 at 14:09, Uwe Ligges
>  wrote:
> >
> >
> > On 02.09.2017 11:40, Christian wrote:
> >>
> >> I consider it quite worth while to introduce into R syntax a nestable
> >> block comment like
> >>
> >> #{
> >> 
> >> }#
> >
> >
> > if(FALSE){
> > 
> > }
> >
> > Best,
> > Uwe Ligges
> >
> >
> >> It would make documentation more easily manageable and lucid.
> >> Is there considerable need for this.
> >>
> >> Please, comment on this.
> >> How about R core?
> >>
> >> Christian
> >
> >
> > __
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > 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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Block comment?

[Jeff Newmiller]

I agree, since one reason for block commenting is to include 
syntactically-invalid information (such as broken code) in the source code.

However, block commenting is not wholly a good thing, as both the R parser and 
human coders often find it challenging to identify where the end of the block 
is, making it difficult to tell whether you are looking at live code or 
comments.  A good editor can add/remove comment marks to "blocks" of lines of 
code, relieving the programmer of tedium while maintaining clarity about which 
lines are active or not.

Block commenting is also a bit of a cultural thing, like using or avoiding tab 
characters in code, or vi-vs-emacs... it is hard to change people's minds about 
it, and potentially inflammatory to try. I think it is safe to say that the 
designers of R were aware of block commenting and consciously chose to not 
include it in the language.
-- 
Sent from my phone. Please excuse my brevity.

On September 2, 2017 7:54:18 AM PDT, "Suzen, Mehmet"  wrote:
>AFAIK block comment is not possible
>it needs to be implemented in R interpreter and defined in the
>parser.'If' solution is not elegant.
>
>On 2 September 2017 at 14:09, Uwe Ligges
> wrote:
>>
>>
>> On 02.09.2017 11:40, Christian wrote:
>>>
>>> I consider it quite worth while to introduce into R syntax a
>nestable
>>> block comment like
>>>
>>> #{
>>> 
>>> }#
>>
>>
>> if(FALSE){
>> 
>> }
>>
>> Best,
>> Uwe Ligges
>>
>>
>>> It would make documentation more easily manageable and lucid.
>>> Is there considerable need for this.
>>>
>>> Please, comment on this.
>>> How about R core?
>>>
>>> Christian
>>
>>
>> __
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> 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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Block comment?

[Bert Gunter]

Uwe showed an R code -ish way to do it. RStudio and probably other R UI's
and IDE's -- which is the way most folks write code, I think -- also make
it easy to do.

Cheers,
Bert




Bert Gunter

"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )

On Sat, Sep 2, 2017 at 7:54 AM, Suzen, Mehmet  wrote:

> AFAIK block comment is not possible
> it needs to be implemented in R interpreter and defined in the
> parser.'If' solution is not elegant.
>
> On 2 September 2017 at 14:09, Uwe Ligges
>  wrote:
> >
> >
> > On 02.09.2017 11:40, Christian wrote:
> >>
> >> I consider it quite worth while to introduce into R syntax a nestable
> >> block comment like
> >>
> >> #{
> >> 
> >> }#
> >
> >
> > if(FALSE){
> > 
> > }
> >
> > Best,
> > Uwe Ligges
> >
> >
> >> It would make documentation more easily manageable and lucid.
> >> Is there considerable need for this.
> >>
> >> Please, comment on this.
> >> How about R core?
> >>
> >> Christian
> >
> >
> > __
> > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> > 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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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.
>

[[alternative HTML version deleted]]

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Block comment?

[Suzen, Mehmet]

AFAIK block comment is not possible
it needs to be implemented in R interpreter and defined in the
parser.'If' solution is not elegant.

On 2 September 2017 at 14:09, Uwe Ligges
 wrote:
>
>
> On 02.09.2017 11:40, Christian wrote:
>>
>> I consider it quite worth while to introduce into R syntax a nestable
>> block comment like
>>
>> #{
>> 
>> }#
>
>
> if(FALSE){
> 
> }
>
> Best,
> Uwe Ligges
>
>
>> It would make documentation more easily manageable and lucid.
>> Is there considerable need for this.
>>
>> Please, comment on this.
>> How about R core?
>>
>> Christian
>
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R-es] Consejo

[Carlos Ortega]

Y hasta hay una "Task View" donde se agrupan y detallan los diferentes
paquetes para encuestas:

CRAN Task View: Official Statistics & Survey Methodology
https://cloud.r-project.org/web/views/OfficialStatistics.html

Saludos,
Carlos Ortega
www.qualityexcellence.es


2017-09-02 15:25 GMT+02:00 Carlos Ortega :

> Hola,
>
> Hay múltiples paquetes en R que permiten trabajar con encuestas, desde
> diseñarlas hasta analizar resultados:
>
> memisc: Tools for Management of Survey Data and the Presentation of
> Analysis Results
> https://cloud.r-project.org/web/packages/memisc/index.html
> -
> surveydata: Tools to Work with Survey Data
> https://cloud.r-project.org/web/packages/surveydata/index.html
> -
> srvyr: 'dplyr'-Like Syntax for Summary Statistics of Survey Data
> https://cloud.r-project.org/web/packages/srvyr/index.html
> -
>
> questionr: Functions to Make Surveys Processing Easier
> https://cloud.r-project.org/web/packages/questionr/index.html
> -
> svyPVpack: A package for complex surveys including plausible values
> https://cloud.r-project.org/web/packages/svyPVpack/index.html
>
> Saludos,
> Carlos Ortega
> www.qualityexcellence.es
>
>
> El 1 de septiembre de 2017, 10:28, Antonio Rodriguez Andres <
> antoniorodriguezandre...@gmail.com> escribió:
>
>> Estimados miembros de la comunidad de R
>>
>> Me gustaria conocer dado que estoy trabajando con datos del World Values
>> Survey, y tengo que recodificar variables y manipularlas,
>> por donde podria empezar a estudiar el uso de R en grandes surveys. Que
>> podria comenzar a la leer.
>> Su respuesta sera bienvenida
>>
>> saludos
>>
>> Antonio
>>
>> --
>>
>> Member, Editorial Committee, *The Economic and Labour Relations Review* (a
>> SAGE journal)
>>
>> http://elr.sagepub.com/
>>
>> Member, Editorial Committee, African Journal of Economic and Management
>> Studies
>>
>> http://emeraldgrouppublishing.com/products/journals/editoria
>> l_team.htm?id=ajems
>>
>> https://www.researchgate.net/profile/Antonio_Andres (Research Gate
>> profile)
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-help-es mailing list
>> R-help-es@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-help-es
>>
>
>
>
> --
> Saludos,
> Carlos Ortega
> www.qualityexcellence.es
>



-- 
Saludos,
Carlos Ortega
www.qualityexcellence.es

[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es

Re: [R-es] Consejo

[Carlos Ortega]

Hola,

Hay múltiples paquetes en R que permiten trabajar con encuestas, desde
diseñarlas hasta analizar resultados:

memisc: Tools for Management of Survey Data and the Presentation of
Analysis Results
https://cloud.r-project.org/web/packages/memisc/index.html
-
surveydata: Tools to Work with Survey Data
https://cloud.r-project.org/web/packages/surveydata/index.html
-
srvyr: 'dplyr'-Like Syntax for Summary Statistics of Survey Data
https://cloud.r-project.org/web/packages/srvyr/index.html
-

questionr: Functions to Make Surveys Processing Easier
https://cloud.r-project.org/web/packages/questionr/index.html
-
svyPVpack: A package for complex surveys including plausible values
https://cloud.r-project.org/web/packages/svyPVpack/index.html

Saludos,
Carlos Ortega
www.qualityexcellence.es


El 1 de septiembre de 2017, 10:28, Antonio Rodriguez Andres <
antoniorodriguezandre...@gmail.com> escribió:

> Estimados miembros de la comunidad de R
>
> Me gustaria conocer dado que estoy trabajando con datos del World Values
> Survey, y tengo que recodificar variables y manipularlas,
> por donde podria empezar a estudiar el uso de R en grandes surveys. Que
> podria comenzar a la leer.
> Su respuesta sera bienvenida
>
> saludos
>
> Antonio
>
> --
>
> Member, Editorial Committee, *The Economic and Labour Relations Review* (a
> SAGE journal)
>
> http://elr.sagepub.com/
>
> Member, Editorial Committee, African Journal of Economic and Management
> Studies
>
> http://emeraldgrouppublishing.com/products/journals/
> editorial_team.htm?id=ajems
>
> https://www.researchgate.net/profile/Antonio_Andres (Research Gate
> profile)
>
> [[alternative HTML version deleted]]
>
> ___
> R-help-es mailing list
> R-help-es@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-help-es
>



-- 
Saludos,
Carlos Ortega
www.qualityexcellence.es

[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es

Re: [R-es] Consejo

[Javier Marcuzzi]

Estimado Antonio Rodriguez Andres

Comienza por donde quieras, lee un libro general, luego otro sobre un tema 
específico, realiza muchos ejercicios, y luego intente manejar muchos datos, de 
lo contrario quedará enredado con los datos propios y las distintas 
alternativas que tiene R para el mismo fin. Estudie todo lo que quiera, pero yo 
en lo personal una gran cantidad de datos no se la doy a una persona en sus 
inicios, no por incapacidad de esta, sino por el peligro de una confusión en el 
ordenamiento y codificación, en otras palabras, hay que asegurar los cimientos 
del edificio, luego discutir el color de la ventana.

Javier Rubén Marcuzzi

De: Antonio Rodriguez Andres
Enviado: viernes, 1 de septiembre de 2017 5:28
Para: r-help-es
Asunto: [R-es] Consejo

Estimados miembros de la comunidad de R

Me gustaria conocer dado que estoy trabajando con datos del World Values
Survey, y tengo que recodificar variables y manipularlas,
por donde podria empezar a estudiar el uso de R en grandes surveys. Que
podria comenzar a la leer.
Su respuesta sera bienvenida

saludos

Antonio

-- 

Member, Editorial Committee, *The Economic and Labour Relations Review* (a
SAGE journal)

http://elr.sagepub.com/

Member, Editorial Committee, African Journal of Economic and Management
Studies

http://emeraldgrouppublishing.com/products/journals/editorial_team.htm?id=ajems

https://www.researchgate.net/profile/Antonio_Andres (Research Gate profile)

[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es


[[alternative HTML version deleted]]

___
R-help-es mailing list
R-help-es@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-help-es

Re: [R] How to use getSymbols() to get annual data

[Duncan Murdoch]

On 01/09/2017 7:37 PM, Yingrui Liu wrote:

Dear Sir/Madam,


How to use getSymbols() to get annual data? For example, I need the annual 
stock price of APPLE from the year 2000 to 2016. How to write the command? I 
only know how to get the daily data. It is:


getSymbols("AAPL",from="2000-01-01",to="2016-12-31")




Presumably you'd need to loop over the years:  get all the daily data in 
a year, calculate the overall High and Low, take the Open from the first 
date, the Close from the last one, and repeat.


Duncan Murdoch

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Block comment?

[Uwe Ligges]

On 02.09.2017 11:40, Christian wrote:
I consider it quite worth while to introduce into R syntax a nestable 
block comment like


#{

}#


if(FALSE){

}

Best,
Uwe Ligges



It would make documentation more easily manageable and lucid.
Is there considerable need for this.

Please, comment on this.
How about R core?

Christian


__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.

Re: [R] Precision error in time index of ts objects

[Andrea Altomani]

Thanks for the very detailed explanation.

I did not create the series using structure(), that was the result of
dump() on an intermediate object created within tsdisagg::ta(), which is
where I found the error in the first place. ta() indeed manipulates .Tsp
directly, rather than using ts. I guess this is a bug in tsdisagg then.

Thanks!


-- 
Andrea Altomani


On Sat, Sep 2, 2017 at 12:31 AM Achim Zeileis 
wrote:

> On Fri, 1 Sep 2017, Andrea Altomani wrote:
>
> > I should have formulated my question in a more specific way.
> >
> > 1. I suspect this is a floating point precision issue. I am not very
> > knowledgeable about R internals, can someone else confirm it?
>
> Yes. If you represent a series with increment 1/12 it depends on how you
> do it. As a simple example consider the following two descriptions of the
> same time point:
>
> 2 - 1/12
> ## [1] 1.916667
>
> 1 + 11/12
> ## [1] 1.916667
>
> However, both are not identical:
>
> (2 - 1/12) == (1 + 11/12)
> ## [1] FALSE
>
> The difference is just the .Machine$double.eps:
>
> (2 - 1/12) - (1 + 11/12)
> ## [1] 2.220446e-16
>
> > 2. Should this be considered a bug or not, because it is "just a
> > precision issue"? Should I report it?
>
> I don't think it is a bug because of the (non-standard) way how you
> created the time series.
>
> > 3. How can it happen? From a quick review of ts.R, it looks like the
> values
> > of the time index are never modified, but only possibly removed. In my
> case:
> >   - x and y have the same index.
> >   - the subtraction operator recognizes this, and create a new ts with
> one
> > entry
> >   - the result of the subtraction has an index which is different from
> the
> > input.
> >  This is very surprising to me, and I am curious to understand the
> problem.
>
> The object 'x' and hence the object 'y' have the same time index. But in
> 'z' a new time index is created which is subtly different from that of
> 'x'. The reason for this is that R doesn't expect an object like 'x' to
> exist.
>
> You should create a "ts" object with ts(), e.g.,
>
> x <- ts(2017, start = c(2017, 6), freqency = 12)
>
> But you created something close to the internal representation...but not
> close enough:
>
> y <- structure(2017, .Tsp = c(2017.416667, 2017.416667, 12), class = "ts")
>
> The print functions prints both print(x) and print(y) as
>
>Jun
> 2017 2017
>
> However, aligning the two time indexes in x - y or ts.intersect(x, y) does
> not work...because they are not the same
>
> as.numeric(time(x)) - as.numeric(time(y))
> ## [1] -3.32e-07
>
> The "ts" code tries to avoid these situations by making many time index
> comparisons only up to a precision of getOption("ts.eps") (1e-5 by
> default) but this is not used everywhere. See ?options:
>
>  'ts.eps': the relative tolerance for certain time series ('ts')
>computations.  Default '1e-05'.
>
> Of course, you could ask for this being used in more places, e.g., in
> stats:::.cbind.ts() where (st > en) is used rather than ((st - en) >
> getOption("ts.eps")). But it's probably safer to just use ts() rather than
> structure(). Or if you use the latter make sure that you do at a high
> enough precision.
>
> hth,
> Z
>
>
> > On Fri, Sep 1, 2017 at 5:53 PM Jeff Newmiller 
> > wrote:
> >
> >> You already know the answer. Why ask?
> >> --
> >> Sent from my phone. Please excuse my brevity.
> >>
> >> On September 1, 2017 7:23:24 AM PDT, Andrea Altomani <
> >> altomani.and...@gmail.com> wrote:
> >>> I have a time series x, and two other series obtained from it:
> >>>
> >>> x <- structure(2017, .Tsp = c(2017.417, 2017.417, 12),
> >>> class = "ts")
> >>> y <- floor(x)
> >>> z <- x-y
> >>>
> >>> I would expect the three series to have exactly the same index.
> >>> However I get the following
> >>>
>  time(x)-time(y)
> >>> Jun
> >>> 2017   0
> >>>
> >>> as expected, but
> >>>
>  time(x)-time(z)
> >>> integer(0)
> >>> Warning message:
> >>> In .cbind.ts(list(e1, e2), c(deparse(substitute(e1))[1L],
> >>> deparse(substitute(e2))[1L]),  :
> >>>  non-intersecting series
> >>>
> >>> and indeed, comparing the indices gives:
> >>>
>  time(x)[1]-time(z)[1]
> >>> [1] 3.183231e-12
> >>>
> >>> Is this a bug in R, or is it one of the expected precision errors due
> >>> to the use of limited precision floats?
> >>>
> >>> I am using R 3.4.0 (2017-04-21) on Windows (64-bit).
> >>>
> >>> Thaks!
> >>>
> >>> Andrea Altomani
> >>>
> >>> __
> >>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> >>> 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.
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-help@r-project.org mailing list -- To 

Re: [R] correlation between nominal and ordinal

[Jim Lemon]

hi merlin,
Check out the hetcor package.

Jim


On Sat, Sep 2, 2017 at 6:25 AM,   wrote:
> I would be very grateful if you would tell me how I can find the degree of
> correlation between a nominal dependent variable and an independent ordinal
> variable. The nominal variable has only two levels: YES and NO.
> thank you very much in advance
> regards,
> merlin
>
> 
>
>
>
>
> --
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> __
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> 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-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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] Block comment?

[Christian]

I consider it quite worth while to introduce into R syntax a nestable 
block comment like


#{

}#

It would make documentation more easily manageable and lucid.
Is there considerable need for this.

Please, comment on this.
How about R core?

Christian
--
Christian Hoffmann
Rigiblickstrasse 15b
CH-8915 Hausen am Albis
Switzerland
Telefon +41-(0)44-7640853

__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.