[R] Greek characters in R studio

[kostas zogopoulos]

How do you read a csv file that contains greek characters as part of the
header (i.e. α, β etc) in R studio?
 Thanks in advance!

[[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] Help with use RMarkdown and knitr in an rdm output to word.doc

[John via R-help]

On Mon, 8 Apr 2019 11:19:12 +
Bill Poling  wrote:

One solution to your problem may be to use an environment like
RStudio.  You can maintain multiple open documents including an rmd
document and using knitr and rmarkdown, add and then run code snippets
the output of which becomes embedded in the generated Word document.  I
use this approach, but the default Word styles are a nuisance and not
suitable for draft reports.  So, following generation of the Word
document you will need to reformat the document.  This works in both
Windows and Linux (where you need Libreoffice installed).

JWDougherty

__
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] [R-pkgs] new R packages for phylogenetic compartive methods

[Krzysztof Bartoszek via R-packages]

Dear all,
I wanted to let you know about four phylogenetic comparative methods (PCM) 
packages that have become available on (3 on CRAN and 1 on GitHub) recently 
that hopefully will be interesting to somebody. Three of them go significantly 
beyond the Brownian motion (BM) and Ornstein-Uhlenbeck (OU) processes.

1) There is a new version of mvSLOUCH available. The most important change is 
that
the inference engine has been completely rewritten. Instead of directly 
evaluating the multivariate normal density formula it uses the PCMBase (R 
package, see below) to obtain the value of the likelihood in linear (in number 
of tip species) instead of quadratic time. Furthermore, as there is no need to 
store the between-species-between-traits variance covariance matrix much larger 
clades, then previously can be handled. From the user's perspective the main 
changes are the interface and increased functionality:
a) the phylogeny has to be now in the phylo (instead of ouch) format,
b) the trait data has to be a matrix (and not a data frame),
c) the package can automatically compare multiple models (BM, OUOU, OUBM and 
different assumed structures on the drift and diffusion matrices of the 
multivariate OU procees), function  estimate.evolutionary.model(), and return 
the one with the lowest AICc (the set of models to consider can either be 
automatically generated or user defined, see generate.model.setups()),
d) the user can set entries of the OU model's parameters to desired values 
(e.g. 0) and this will be fixed through the whole estimation,
e) a number of control parameters to be passed to the estimation procedure and 
optim() are available for the user to manipulate

2) PCMFit: the goal of PCMFit is to provide a generic tool for inference and 
selection of phylogenetic comparative models (PCMs). Currently, the package 
implements Gaussian and mixed Gaussian phylogenetic models (MGPM) over all tree 
types (including non-ultrametric and polytomic trees). The package supports 
non-existing traits or missing measurements for some of the traits on some of 
the species. The package supports specifying measurement error associated with 
each tip of the tree or inferring a measurement error parameter for a group of 
tips. The Gaussian phylogenetic models include various parametrizations of 
Brownian motion (BM) and Ornstein-Uhlenbeck (OU) multivariate branching 
processes. The mixed Gaussian models represent models with shifts in the model 
parameters as well as the type of model at points of the tree. Each shift-point 
is described as a pair of a shift-node and associated type of model (e.g. OU or 
BM) driving the trait evolution from the beginning of the branch le
 ading to the shift-node toward the shift-node and its descendants until 
reaching a tip or another shift-point. The function PCMFit is used to fit a 
given PCM or a MGPM for a given tree with specified shift-points. The function 
PCMFitMixed is used to fit an ensemble of possible MGPMs over a tree for which 
the shift-points are unknown. This function can perform model selection of the 
best MGPM for a given tree and data according to an information loss function 
such as the Akaike information criterion (AIC). The package has been thoroughly 
tested and applied to real data in the related research article entitled 
"Automatic Generation of Evolutionary Hypotheses using Mixed Gaussian 
Phylogenetic Models" (currently in review). Currently, the package is available 
from https://github.com/venelin/PCMFit . The web-page 
https://venelin.github.io/PCMFit/ provides access to documentation and related 
resources.

3) PCMBase: the computational engine that mvSLOUCH uses. Given a phylogeny 
(phylo format), traits' (multivariate) measurements and a user provided model 
of the traits' evolution the package calculates the likelihood. The family of 
allowed models is rather general. The package can handle any model for which 
lineages after speciation do not interact and the density of the transition 
along a branch is:
i) Gaussian
ii) the mean at the end of the branch depends linearly on the trait value at 
the start of the branch
iii) the covariance matrix does not depend on the value at the start of the 
branch
The likelihood is calculated in linear in number of tip species time.
The package is described in
Venelin Mitov, Krzysztof Bartoszek, Georgios Asimomitis, Tanja Stadler (2018).
Fast likelihood evaluation for multivariate phylogenetic comparative methods: 
the PCMBase R package
arXiv URL https://arxiv.org/abs/1809.09014 .

3) pcmabc: a package that allows for simulation and ABC estimation under any 
model for which the user can provide a function to simulate trait 
(discrete/continuous, uni- or multivariate) evolution along a branch. Special 
support is given for SDE based models, using the yuima package.
Krzysztof Bartoszek, Pietro Lio' (2019) Modelling trait dependent speciation 
with Approximate Bayesian Computation. Acta Physica Polonica B 

Re: [R] Help with use RMarkdown and knitr in an rdm output to word.doc

[Bill Poling]

Good morning Jeff.

It's not elegant, nuts actually, but it works.

A temporary solution to my time sensitive report while I work on my RMarkdown 
to Word.docx skills.

I run the routine in knit to HTML, save that to PDF, then convert PDF to the 
Word doc and go from there.

Thanks again for all your advice.

WHP

-Original Message-
From: Bill Poling
Sent: Sunday, April 7, 2019 11:17 AM
To: Jeff Newmiller ; r-help@r-project.org; r-help 
(r-help@r-project.org) 
Cc: Bill Poling 
Subject: RE: [R] Help with use RMarkdown and knitr in an rdm output to word.doc

Hi Jeff, yes guilty as charged, I do depend on copying snippets too much, then 
look for the documentation when it blows up.

I will heed your advice and review further the help page for the 
rmarkdown::word_document and the other resources as well.

Thanks again for taking the time Jeff I really have learned a lot from your 
assistance.

WHP


From: Jeff Newmiller 
Sent: Sunday, April 7, 2019 9:05 AM
To: Bill Poling ; r-help@r-project.org; r-help 
(r-help@r-project.org) 
Subject: RE: [R] Help with use RMarkdown and knitr in an rdm output to word.doc

The kable_styling function in your code does not appear in the example docx 
howto, so no, they are not the same.

Bill, at some point you have to stop depending on copying snippets from blogs 
and read the function documentation, especially the arguments and values 
sections. The docs for the kable_styling function specifically mention only 
HTML and LaTeX that I warned you about. It has to generate pure markdown to be 
converted to docx.

Also, you probably shouldn't use the results='asis' chunk setting in most cases 
for docx output.

For example, if you read the help page for the rmarkdown::word_document 
function you should find a keep_md argument. Rmarkdown uses the YAML to setup 
the call to this function so you can write

output:
word_document:
keep_md: yes

for the purpose of looking at the raw markdown after knitr is done processing 
chunks. Applied to your code with the kable_styling function, you should see an 
extra md output file as it looks just before being converted to docx, with a 
bunch of HTML code in the md file where that chunk used to be. This would be 
fine if the final destination was a web browser, but not for converting to 
word. If you remove that function then the md file should have a plain markdown 
table... you can tell because it is much simpler to read than the html in raw 
form is.

Note that markdown is intentionally simple... there is a lot that you cannot 
convey through it about appearance. You are shackling yourself to a lower 
standard of appearance by using it. I inevitably have to manually reformat the 
results if I share the file for further editing. If that is unacceptable for 
your case then consider using the officer package... but your finalfit package 
won't play well with that.

On April 7, 2019 3:07:53 AM PDT, Bill Poling  
wrote:
>Thanks Jeff, yes well I have followed the Harrison tutorial and my
>chunks are the same as his examples which appear to work fine for him?
>I am stymied.
>
>#https://www.datasurg.net/2018/05/22/finalfit-knitr-and-r-markdown-for-quick-results/
>rg.net
>
>I will keep working on it though, many thanks.
>
>WHP
>
>
>
>
>From: Jeff Newmiller 
>Sent: Saturday, April 6, 2019 6:51 PM
>To: Bill Poling ;
>mailto:r-help@r-project.org; r-help
>(mailto:r-help@r-project.org) 
>Subject: RE: [R] Help with use RMarkdown and knitr in an rdm output to
>word.doc
>
>Read the help files for the functions in each code block that are
>actually producing output that will be displayed. One of them is not
>compatible with docx file output.
>
>On April 6, 2019 2:44:55 PM PDT, Bill Poling
> wrote:
>>Thank you Jeff, I am so darn close, I solve one problem and another
>>emerges!
>>
>>However, I realized that back in July when I made my first and, up
>>until this weekend, only attempt at this I was following the original
>>url that was reposted by R-Bloggers that I mentioned in my original
>>post earlier.
>>#https://www.datasurg.net/2018/05/16/elegant-regression-results-tables-and-plots-the-finalfit-package/
>>urg.net
>>
>>Low and behold realized I had asked the author (Ewen Harrison with
>>DataSurg) these questions back then in the comments, UGH!
>>But since I ditched the idea in frustrationback then and I did not
>>follow-up I hadn't realized the author created a companion url for
>this
>>very topic, how to get from .Rmd to word/PDF etc..
>>
>>I located his companion reference url to the original.
>>
>>#https://www.datasurg.net/2018/05/22/finalfit-knitr-and-r-markdown-for-quick-results/
>>urg.net
>>
>>So following his further instructions I have made more progress,
>>however, as I mention above the final document remains elusive.
>>
>>SO I did some further googling and perused these sites as well
>>