Running R on linux (see version below output below)
I experience weird behavior with sprintf converting dec to hex.
Does anybody know what could explain this? (i.e. first conversion works fine, second returns an error regarding numeric):
> sprintf("%x",2109440182)
[1] "7dbb80b6"
> sprintf("%x",2151028214)
Error in sprintf("%x", 2151028214) :
invalid format '%x'; use format %f, %e, %g or %a for numeric objects
version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 3
minor 0.1
year 2013
month 05
day 16
svn rev 62743
language R
version.string R version 3.0.1 (2013-05-16)
nickname Good Sport
Thanks, Michael
gcc : format ‘%x’ expects an argument of type ‘unsigned int’, but argument 2 has type ‘long int’.
I guess the number is larger that an unsigned int. Max range in my system is 2147483648,
So this is correct:
printf("%x\n", 2147483647);
Related
This question already has answers here:
Convert accented characters into ascii character
(2 answers)
Closed 1 year ago.
I have the following data:
authors <- c("Fernando Carré", "Adrüne Coça", "Pìso Därço")
And I want to extract non-english characters and convert them into ASCII, but without the spaces. This is what I have tried:
gsub("[^[:alnum:]]","",authors)
But it returns:
[1] "FernandoCarré" "AdrüneCoça" "PìsoDärço"
It should return:
"Fernando Carre" "Adrune Coca", "Piso Darco"
Any help will be greatly appreciated.
Thanks for Onyambu correction, the following statement is not correct
The expression [[:alnum:]] is made for the package stringr only. It cannot be used in other packages. Hence we can use
But here is what I got from the console.
> authors <- c("Fernando Carré", "Adrüne Coça", "Pìso Därço")
> iconv(authors ,to="ASCII//TRANSLIT")
[1] "Fernando Carre" "Adrune Coca" "Piso Darco"
> sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS
Edit: The floating-point issue has been discussed previously (not only on this site, please see the links below). Therefore this question is essentially a duplicate, however it may be useful to link the well-known floating-point issue to floor division in R.
In this version of R
R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
I have observed an inconsistency:
> 65 %/% 5
[1] 13
> 6.5 %/% .5
[1] 13
> .65 %/% .05
[1] 12
> .065 %/% .005
[1] 13
It may be a known issue probably related to floating-point arithmetic.
How to deal with this issue in everyday calculations in order to avoid wrong numbers?
As assumed, my question is not new and is intrinsic to floating-point numbers.
As far as I can tell the best way to cope with this issue is to understand it and accept its existence.
More information can be found here, here and here.
Then we have the R-FAQ and the R Inferno; I found this links in the mentioned pages.
When I have no decimal, it is fine:
time = parse_date_time('5:55', 'MS')
second(time)
# 55
When I add a decimal, it is off by 1
time = parse_date_time('5:55.34', 'MS')
second(time)
# 56.34
It obviously detects the decimal place I originally had, but it seems to be still rounding the unit digit up by one.
Is this intended behavior?
Extra Information:
This occurs in both versions 1.7.1 and 1.7.3 on Windows 10
This occurs in 1.7.1on Mac OS Sierra
Shouldn't you be using ms?
library(lubridate)
time = ms('5:55.34')
second(time)
#[1] 55.34
R newbie here, re-building Python pipeline in R.
d is a data.frame():
$ day (chr) "2016-10-13", ...
$ city_name (chr) "SF", ...
$ type (chr) "Green", ...
$ count (int) 10, ...
I'm doing a spread() on the data from tidyr package:
d %>% spread(type,count)
Works fine running locally (Mac) with:
R version 3.3.0 (2016-05-03)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.5 (El Capitan)
tidyr_0.6.1
I run the identical command on a Linux box, on the same input d, but it returns an error:
Error in `[.data.table`(.variables, lengths != 0) : i evaluates to a logical vector length 3 but there are 930 rows. Recycling of logical i is no longer allowed as it hides more bugs than is worth the rare convenience. Explicitly use rep(...,length=.N) if you really need to recycle.
On Linux, I'm running:
R version 3.2.5 (2016-04-14)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu precise (12.04.5 LTS)
tidyr_0.6.0
Any idea what this error means, and why it would be thrown?
Edit: fixed this after updating tidyr on Linux, and re-starting the R session.
In Rstudio (using R 3.1.1) when I run this,
length(unique(sort(c(outer(2:100,2:100,"^")))))
# 9220
In R 3.1.1 when I run this,
length(unique(sort(c(outer(2:100,2:100,"^")))))
# 9183
(the correct output is 9183)
I can't figure out why... help is greatly appreciated
As David Arenburg notes, this is a difference between 32-bit and 64-bit R versions, at least on Windows machines. Presumably, some sort of rounding error is involved. Interestingly, it is the 32-bit R gets the answer right, whereas the 64-bit R finds too many unique numbers.
First to confirm that 9183 is indeed the correct answer, I used the gmp package (a wrapper for the C multiple precision arithmetic library GMP), which provides results that are not subject to rounding errors:
library(gmp)
x <- as.bigz(2:100)
length(unique(do.call(c, sapply(x, function(X) x^X))))
[1] 9183
Here are the results from my 32-bit R:
length(unique(sort(c(outer(2:100,2:100,"^")))))
# [1] 9183
R.version[1:7] _
# platform i386-w64-mingw32
# arch i386
# os mingw32
# system i386, mingw32
# status
# major 3
# minor 1.2
And here are the results from my 64-bit R:
length(unique(sort(c(outer(2:100,2:100,"^")))))
# [1] 9220
R.version[1:7]
# platform x86_64-w64-mingw32
# arch x86_64
# os mingw32
# system x86_64, mingw32
# status
# major 3
# minor 1.2