similar to: R string comparisons may vary with platform (plain text)

On Sat, Nov 22, 2014 at 12:42 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 22/11/2014, 2:59 PM, Stuart Ambler wrote: >> A colleague?s R program behaved differently when I ran it, and we thought >> we traced it probably to different results from string comparisons as >> below, with different R versions. However the platforms also differed. A >>

On 22/11/2014, 2:59 PM, Stuart Ambler wrote: > A colleague?s R program behaved differently when I ran it, and we thought > we traced it probably to different results from string comparisons as > below, with different R versions. However the platforms also differed. A > friend ran it on a few machines and found that the comparison behavior > didn?t correlate with R version, but

On 23/11/2014 09:39, peter dalgaard wrote: > >> On 23 Nov 2014, at 01:05 , Henrik Bengtsson <hb at biostat.ucsf.edu> wrote: >> >> On Sat, Nov 22, 2014 at 12:42 PM, Duncan Murdoch >> <murdoch.duncan at gmail.com> wrote: >>> On 22/11/2014, 2:59 PM, Stuart Ambler wrote: >>>> A colleague?s R program behaved differently when I ran it, and we

> On 23 Nov 2014, at 01:05 , Henrik Bengtsson <hb at biostat.ucsf.edu> wrote: > > On Sat, Nov 22, 2014 at 12:42 PM, Duncan Murdoch > <murdoch.duncan at gmail.com> wrote: >> On 22/11/2014, 2:59 PM, Stuart Ambler wrote: >>> A colleague?s R program behaved differently when I ran it, and we thought >>> we traced it probably to different results from

For many scientific applications one is really dealing with ASCII characters and LC_COLLATE="C", even if the user is running in non-C locales. What robust approaches (if any?) are available to write code that sorts in a locale-independent way? The Note in ?Sys.setlocale is not overly optimistic about setting the locale within a session. Martin Morgan On 11/23/2014 03:44 AM, Prof

x <- "\u0663" y <- 3 x == y # FALSE rank(c(x, y)) # c(1.5, 1.5) -- http://had.co.nz/

Yes, collation is a strange thing, and? Collation order will depend on locale settings, and there are quite a few cases where the collation order of two items is not defined. To add to the confusion, on OSX Mavericks, I see > x <- "\u0663" > y <- 3 > > x == y [1] FALSE > rank(c(x, y)) [1] 2 1 > x [1] "?" > x == y [1] FALSE > x > y [1] TRUE

Hi, pnorm(-1.53,0,1) under version 3.0.2 gives 0.05155075. I am pretty sure it should be 0.063. Is there something wrong with this version of R? I am using: R version 3.0.2 (2013-09-25) -- "Frisbee Sailing" Copyright (C) 2013 The R Foundation for Statistical Computing Platform: i686-pc-linux-gnu (32-bit) -- Tom [[alternative HTML version deleted]]

The following caused a hard-to-diagnose problem for a user of the survey package. Presumably this is a strange Unicode thing, but is there a convenient reference for how the collation order is determined? I am surprised that adding the same character to the end of two strings of the same length can change the sorting order. in en_US.utf8 locale > "1//"<"10/" [1]

No me ha funcionado, pero muchas gracias Daniel Merino. Al final he solucionado mi problema generando el HTML desde una máquina vertual Windows, como hacía Jorge Ayuso. Gracias a todos por la ayuda :) Elvira. > El 23/10/2013, a las 10:38, <miguel.angel.rodriguez.muinos en sergas.es> escribió: > > Hola Elvira. > > .. y ese comando te ha funcionado???? > :-) > >

Diverted from ESS-help. It is really about R's LANGUAGE, locales and then a wish for sessionInfo() : >>>>> Sparapani, Rodney <rsparapa at mcw.edu> >>>>> on Thu, 20 Feb 2014 19:39:33 +0000 writes: >> Just guessing: perhaps this is something that is set when >> R is initialized and not queried every time something is >>

I've just installed r-base (several times!) using the instructions at http://cran.us.r-project.org/bin/linux/ubuntu/ and for some reason it is not creating a /etc/R/ldpaths file. I've tried a few times, tried purging, and removing everything in /etc/R and /usr/lib/R as suggested by Dirk, and reinstalling but still get $ R /usr/bin/R: line 236: /usr/lib/R/etc/ldpaths: No such file

On RedHat Enterprise Linux 6, the test below fails (this is using the stock GCC 4.4.7) from R-devel r72707. LC_CTYPE is unset when I run it, but LANG=en_US.UTF-8 It also failed "yesterday" where as far as I recall the test code looked a bit different. Best, Kasper > ## Results differed by platform, but some gave incorrect results on string 10. > > > ## str() on large

>>>>> Kasper Daniel Hansen <kasperdanielhansen at gmail.com> >>>>> on Fri, 19 May 2017 20:09:24 -0400 writes: > I rebuilt R with > export LC_CTYPE=en_US.UTF-8 > and the test still fail. Surprisingly, when I run R from the bin directory > and execute the test code, it runs without error: >> oloc <-

Hi all, Can anyone help me understand why an implicit print (i.e. just typing df at the console), is so much slower than an explicit print (i.e. print(df)) in the example below? I see the difference in both Rstudio and in a terminal. # Construct large df as quickly as possible dummy <- 1:18e6 df <- lapply(1:10, function(x) dummy) names(df) <- letters[1:10] class(df) <-

Hi, read.dcf() can modify the locale variable LC_CTYPE, and here is a minimal example: > Sys.getlocale('LC_CTYPE') [1] "en_US.UTF-8" > read.dcf(textConnection('a: b'), all = TRUE) a 1 b > Sys.getlocale('LC_CTYPE') [1] "C" After diagnosing the problem, it seems the on.exit() call in read.dcf() is the culprit:

Hello everyone, I am new to R and I have experienced some bugs when using Rterm on Windows. Chinese characters in the console output are discarded by Rterm, and trying to type them into the console will crash the Rterm application. ---ENVIRONMENT--- Platform = x86_64-w64-mingw32 OS = Windows 10 Pro 1709 chs R version = 3.4.3 Active code page = 936 (Simplified Chinese) ---STEPS TO

OK. I give up. I'll ask a stupid question. How do I get the $!#@*$ signif stars line printed by summaries to not look extremely bizarre in the latex produced by Sweave? For example, see p. 7 of http://www.stat.umn.edu/geyer/aster/library/aster/doc/tutor.pdf I can see what the problem is. R emits non-ascii characters (as it is supposed to do), Sweave puts them in the tex file, and

Full_Name: Graeme Ambler Version: 1.7.1 OS: Red Hat Linux 9 Submission from: (NULL) (137.222.80.161) Typing Shift-Return in R causes a segmentation fault. I am using the Red Hat 9 RPM from CRAN.

I am consistently getting the following error from puppetd when an exec resource is triggered by a refresh event: Apr 23 10:36:11 mailhub puppetd[37884]: Reopening log files Apr 23 10:36:11 mailhub puppetd[37884]: Starting Puppet client version 0.22.3 Apr 23 10:36:11 mailhub puppetd[37884]: Starting configuration run Apr 23 10:36:12 mailhub puppetd[37884]: