in a database I have strings stored that contain special characters such as "§".
Using the command
sqlQuery()
from package RODBC "§" is translated to "?". This is also the case for characters such as " ' " as it can be found in French words.
Of course I can not replace every "?" by one of the special characters after the query. Does anybody have an idea for this problem? I work under windows 7.
As requested the out put of sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets methods base
other attached packages:
[1] timeDate_2160.97 gridExtra_0.9.1 reshape2_1.2.2 RODBC_1.3-6 ggplot2_0.9.3.1 plyr_1.8
[7] Runiversal_1.0.2
loaded via a namespace (and not attached):
[1] colorspace_1.2-1 dichromat_2.0-0 digest_0.6.3 gtable_0.1.2 labeling_0.1 MASS_7.3-21
[7] munsell_0.4 proto_0.3-10 RColorBrewer_1.0-5 scales_0.2.3 stringr_0.6.2 tools_2.14.1
If you are seeing an issue where you are using sqlSave() in R to send to MYSQL where not all of the data streams through, it's likely because of special characters. The key is to make sure the character collation is set to the same in both..I found latin1 works best.
Related
Even if I copy paste example from blog.fosstrading.com/2011/08/tactical-asset-allocation-using.html I get this error:
error in PosLimit[, "MaxPos"] : incorrect number of dimensions
Is this a bug or am I missing something?
Output from sessionInfo():
R version 3.2.2 (2015-08-14)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] dplyr_0.4.3 quantstrat_0.9.1687 foreach_1.4.2
[4] blotter_0.9.1695 PerformanceAnalytics_1.4.3662 FinancialInstrument_1.2.0
[7] quantmod_0.4-5 TTR_0.23-0 xts_0.9-7
[10] zoo_1.7-12
loaded via a namespace (and not attached):
[1] Rcpp_0.12.1 lattice_0.20-33 codetools_0.2-14 assertthat_0.1 grid_3.2.2
[6] R6_2.1.1 DBI_0.3.1 magrittr_1.5 iterators_1.0.7 tools_3.2.2
[11] parallel_3.2.2
You have dplyr loaded. It defines a lag function that masks the generic function, stats::lag. dplyr::lag does not do any method dispatch, so there's a lag method somewhere that isn't being called when it should be.
dplyr also masks the first and last generics defined in xts, which may also cause problems.
A short-term work-around is to call library(dplyr) first, so first and last in xts will mask their couterparts in dplyr. The long-term solution is that all packages should explicitly import all functions they use to avoid issues caused by the sequence in which packages are loaded/attached (note that user's non-packaged code will still be affected by package load/attach order).
I am working with large datasets in R and some of the computations are too heavy for my machine in terms of RAM (cannot allocate vector of size n Mb).
sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252 LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252 LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] MASS_7.3-35 lubridate_1.3.3 nlstools_1.0-0 stringr_0.6.2 numbers_0.5-2 plyr_1.8.1
[7] simecol_0.8-4 deSolve_1.11 Quandl_2.4.0 xts_0.9-7 zoo_1.7-11 data.table_1.9.4
[13] RODBC_1.3-10
loaded via a namespace (and not attached):
[1] bitops_1.0-6 chron_2.3-45 digest_0.6.8 grid_3.1.2 lattice_0.20-29 memoise_0.2.1
[7] Rcpp_0.11.4 RCurl_1.95-4.5 reshape2_1.4.1 RJSONIO_1.3-0 tools_3.1.2
I have access to an Amazon EC2 external server with up to 30 GB RAM which should be enough. My question is how I can run an R script on this external server using my local machine? Is there a function for this?
you would have to put script on the external machine and then run it:
ssh user_name#123.321.123.123 'my_script.r'
Much nicer way of doing that would be to use RStudio server.
As a reproducible example, we can use the ui.R and server.R files from:
https://github.com/bcaffo/courses/tree/master/09_DevelopingDataProducts/shiny/inputApp
When I run runApp() in RStudio the internal RStudio viewer displays an interface like this:
which is good, but when I click "Open in Browser" the Chrome and Firefox versions looks like this:
What gives?
> sessionInfo()
R version 3.1.2 (2014-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets
[6] methods base
other attached packages:
[1] shiny_0.10.2.1
loaded via a namespace (and not attached):
[1] digest_0.6.4 htmltools_0.2.6 httpuv_1.3.2
[4] mime_0.2 R6_2.0.1 Rcpp_0.11.3
[7] RJSONIO_1.3-0 tools_3.1.2 xtable_1.7-4
I'm trying to install shinyapps from github. However, every time I run devtools::install_github('rstudio/shinyapps'), my R session crashes. I have just installed all the requisite packages so I am sure that I have the latest versions.
It seems that trying to install any packages from github causes the crash
Any help would be greatly appreciated
Edit: Here is the output from sessionInfo():
R version 3.1.0 (2014-04-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252 LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] RCurl_1.95-4.2 bitops_1.0-6 devtools_1.5
loaded via a namespace (and not attached):
[1] colorspace_1.2-4 digest_0.6.4 evaluate_0.5.5 ggplot2_1.0.0 grid_3.1.0 gtable_0.1.2 httr_0.3 MASS_7.3-31 memoise_0.2.1 munsell_0.4.2 parallel_3.1.0 plyr_1.8.1
[13] proto_0.3-10 Rcpp_0.11.2 reshape2_1.4 scales_0.2.4 stringr_0.6.2 tools_3.1.0 whisker_0.3-2 `
I'm trying to export a data frame with Arabic text in R.
When R imports Arabic text it converts it to UTF-8 codes. Like this:
<U+0627><U+0644><U+0641><U+0631><U+0639> <U+0627><U+0644><U+062A><U+0634><U+0631><U+064A><U+0639><U+064A><U+060C> <U+0627><U+0644><U+0641><U+0631><U+0639> <U+0627><U+0644><U+062A><U+0646><U+0641><U+064A><U+0630><U+064A><U+060C><U+0627><U+0644><U+0641><U+0631><U+0639> <U+0627><U+0644><U+0642><U+0636><U+0627><U+0626><U+064A>. <U+0627><U+0644><U+062D><U+0643><U+0648><U+0645><U+0629> <U+0627><U+0644><U+0641><U+062F><U+0631><U+0627><U+0644><U+064A>
Unfortunately, I can't get it to turn back into readable Arabic when exporting. Below is code I'm using...
write.csv(my.data,"data.csv", fileEncoding='UTF-8')
Anybody have a solution?
Also, here is my session info.
R version 3.0.1 (2013-05-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] ggplot2_0.9.3.1
loaded via a namespace (and not attached):
[1] colorspace_1.2-2 dichromat_2.0-0 digest_0.6.3 grid_3.0.1 gtable_0.1.2
[6] labeling_0.2 MASS_7.3-27 munsell_0.4.2 plyr_1.8 proto_0.3-10
[11] RColorBrewer_1.0-5 reshape2_1.2.2 scales_0.2.3 stringr_0.6.2 tools_3.0.1
This code worked with me so I am sharing it:
Sys.setlocale("LC_CTYPE", "arabic" )
write.csv(group$message, file = 'posts.txt', fileEncoding = "UTF-8")
If you save the file as csv it will not work. You have to save it as txt.
You'll have to install and use locales. It's difficult and sometimes doesn't work.
There's some solutions and code offered here: Writing data isn't preserving encoding
Keep in mind that you actually HAVE to install language packs for your operating system and for some Windows versions there aren't any available separately at all.