When making data functions for Tibco SpotFire - build version 7.8.1.0.9 - I use RStudio - R version 3.5.2 (2018-12-20) - for writing and debugging the functions, and then I copy my code into SpotFire when I am done.
On several occasions, I have noticed inconsistencies between how R code runs between RStudio and SpotFire. Whenever these arise, the results produced by RStudio are consistent with the online R documentation, and those produced by SpotFire are not.
I have not been tracking examples as I go, but I do have my most recent example of this available. Below is a simplified version of that data function. It and the paragraph below it are more in-the-weeds than is ideal for this post, but hopefully it demonstrates the type of issue I keep coming across.
# converts date strings "yyyy-MM-dd" to week number strings "yyyyww",
# where ww is the week number in the year (ISO 8601 convention.)
# dates is a vector (R) or column in a data table (SpotFire)
# containing strings, formatted as "yyyy-MM-dd". In SpotFire,
# the data type for the column is String, not Date.
Week <- strftime(dates, format="%Y%V")
A link to the documentation for R's strftime function is here. RStudio
returns values like "201901", which is what the documentation indicates it should for the format argument used. SpotFire returns values like "2019" - no week number info is there at all, against the documentation. If I replace format="%Y%V" with format="%Y%W", RStudio returns values like "201900", which again is what is indicated by the documentation. As far as I can tell, SpotFire returns the values it is supposed to with format="%Y%V" - so I guess internally it changes the inputs in some manner.
My basic question is: How do I get around this sort of thing, and how can I know when/how SpotFire is going to mess with my functions and their variables in some weird manner? E.g., is there some special version of R that Tibco uses that is not the documented R, or is there documentation that Tibco provides for how it's going to internally handle R code?
Thanks for any help.
The short answer is yes. Spotfire natively runs TERR, a special version of R that TIBCO uses. This link gives the main differences but it is not exhaustive: R/4.4.0/doc/html/Differences_Between_TERR_and_R/differences.html
They are two separate language engines. If you google 'TIBCO TERR' you will find a lot of information. You will find the exact version of TERR you are running in your Spotfire by going to Tools > TERR Tools.
You can use RStudio and point it to where TERR is installed on your machine, the same way you point it to your R installation. This way you can verify your code does what you expect. It looks in this case that %V is not supported but %W is. You can also use open source R within Spotfire, but then you need a statistics server.
Gaia
Related
I am trying to access data from variables within a NetCDF file that contains hierarchical groups using R. For example:
I can't find anything about how to do this in the RNetCDF documentation - though this seems to be out of date online.
Latest version: https://www.rdocumentation.org/packages/RNetCDF/versions/2.6-1
Latest documented version: https://www.rdocumentation.org/packages/RNetCDF/versions/1.9-1
I am open to using ncdf4, though would rather do this in RNetCDF since I think the syntax is easier to read and I use R only for teaching purposes.
I can do this in Python using xarray - but need an R solution in this case. Thanks!
I have been writing code in R studio and tried to move it over to Jupyer Books to share it with people.
The code all works in R studio but when I run it in Jupyer Books, as.date() does not convert the date column which begins as a factor into a date which then means I have no data when I subset by date later on.
Has anyone had this happen and know a solution? Or will I just need to use lubridate or similar to convert the date?
Thanks,
Dave
My guess is that you are running different R versions in both places. Run R.version.string at both the places to check which version of R you are running at each of them. Since R 4.0.0 the default behaviour of R changed when importing string data into R. Previously they were imported as factors and now (since 4.0.0) they are imported as characters.
The solution is to import your dataset with stringsAsFactors = FALSE in both the places to see the same output at both the places.
data <- read.csv('filename.csv', stringsAsFactors = FALSE)
Since a couple of days I get the following error message in RStudio from time to time and can't figure out what is causing it.
When I write in the console window to address a data.frame followed by $ to address a specific column in the data.frame (for example df$SomeVariable), the following message is shown in the console window and is printed over an over with every letter I type
Error in gsub(reStrip, "", completions, perl = TRUE) :
input string 38 is invalid UTF-8
The error message doesn't have any real effect. Everything works just fine except the automatic completion of the variable name.
I'm using R version 3.4.4 and RStudio Version 1.0.143 on a Windows computer. In the R script I am currently working on I don't use gsub or any other "string" or regular expression function for that matter. The issue appeared with various data.frames and various types of variables in the data.frames (numeric, integer, date, factor, etc.). It also happens with various packages. Currently, I am using combinations of the packages readr, dplyr, plm, lfe, readstata13, infuser, and RPostgres. The issue disappears for a while after closing RStudio and opening it again but re-appears after working for a while.
Does anyone have an idea what may cause this and how to fix it?
I used to have the same problem a few days ago. I made some research and i found that when you import the dataset, you can change the encoding. Change the encoding to "latin1" and maybe that could fix your problem. Sorry for my poor english, im from Southamerica. Hope it works.
My question is if an object in R saved to binary format using the save function can be different if saved from different (but recent) versions of R.
That is because I have a script that makes some calculations and save its results to a file. When reproducing the same calculations later, I decided to compare the two files using
diff --binary -s mv3p.Rdata mv3p.Rdata.backup
To my surprise the two files are different. However when analysing the contents in R, they are identical.
The new version is 3.3.1. I believe the older version have been created by R 3.3.0 but it could also be by 3.2.x, I am not 100% sure. I used the save command with only the object I wanted to save and the filename arguments.
So my question is : is it normal that the same object is written differently in different versions of R? is it documented somewhere? How can I be sure to be able to reproduce exactly the same file? On what can it depend (R version, OS, processor architecture, etc...)
Please , I am NOT asking if versions can be read by another version of R and I am NOT asking about very old R versions.
R data files also include the R version used to write it. That's one reason the files may be different. See here on documentation: http://biostat.mc.vanderbilt.edu/wiki/Main/RBinaryFormat
Also, you can use save(..., ascii=T) to see the difference in plain text.
I am using plyr to rename the columns of a large data set to a shorter aliases. The from names are very long with occasional unusual symbols (i.e. Â) This code works in in R Studio when I manually (i.e. Ctrl+R) execute the code. No errors.
However, when it is run using source in another script and/or in the standard Rgui (even using Ctrl+R), it recognizes some of the names in the from statement, but not others, which are identified in the error:
The following from values were not present in x
32/64 bit doesn't seem to make a difference. Can't identify character or value that is producing the error. Any solutions?
Should this be posted as an issue on the plyr Github?
I have prepared a dummy replica of the data set here.
The program that works in R Studio, but not in standard Rgui is here.
The code for the "source" call that produces errors is
source("dftest.R")
All software and packages updated on 3/18/2016.
See similar but unrelated question here.
Looks like copying the code from R Studio text editor and pasting into native client text editor, and then saving, solved both the source problem and the native client problem.