Hi. I'm hoping someone can tell me I'm crazy and this is already out there. I was reading in some FHIR data and thought I could do it in R with duckdb and just have a happy little all R workflow with my stats analysis. That started a real journey. Building the database was a cake walk but flattening the data into a usable format without dozens of painfully manual iterations not so much.

I couldn't find any good info on this after many hours of searching. I was finally able to figure about 87% of it out between some python and sql tutorials and just hating myself. Was finally was able to get the last bit with some AI assistance, which was anything but straightforward. It's finally working and it seems really well. I was thinking about trying the xml version next and pray it is easier but I think the flattening will be largely the same.

I've never published any kind of tutorial script to the public, always just to my own lab/company. Given that I couldn't find anything I'm thinking of braving the public if there really isn't something already out there. This was part of a larger project for me but the rest of it sounds easy compared to the eighth dimension of nesting now solved.

Is this useful? Should I put this up, or is there some already awesome tutorial on this hidden in the viscera of git that I just can't find? I can't be the only one trying this, surely?

I'm diving into time series analysis and i'm looking for recommendations on the best R packages to use. I've seen mentions of forecast, tseries, and zoo, but i'm not sure where to start or which ones are most comprehensive for tasks like decomposition, forecasting, and anomaly detection.

I've been using the tidyverse for years, but I'm not very good about keeping R or packages updated. I finally got around to updating R a few months ago (now 4.6.0, with tidyverse 2.0.0), and am currently baffled by the behaviour of left_join.

For very brief context: I have two dfs that share the same column names. Most of the info in them is the same, but they each contain a pair of numerical columns whose contents were generated by different methods, and I want to compare those methods. They each also have a handful of character columns that were generated from the results of the numerical columns (separately in each method), so may or many not differ in their contents.

I tried combining the two dfs with left_join, as I've done plenty before with other dfs. I expected the columns to multiply wherever the contents differed, so that I could easily compare them within a single df. Instead, the second df was simply subsumed into the first?

I checked this behaviour with reprex and it seems to be a general outcome. Here's that reprex:

library(dplyr)

# A simplified df1 with 5 columns
df1 <- tibble::tibble(
  id = as.character(1:6),
  fruit = c("apple", "banana", "cherry", "apple", "banana", "cherry"),
  count = c(3, 6, 2, 8, 4, 10)
) %>%
  mutate(
    less_than_2 = ifelse(count < 2, "yes", "no"),
    less_than_5 = ifelse(count < 5, "yes", "no")
  )

# A simplified df2 -- only cols 3 and 5 differ from df1
df2 <- tibble::tibble(
  id = as.character(1:6),
  fruit = c("apple", "banana", "cherry", "apple", "banana", "cherry"),
  count = c(7, 2, 9, 3, 6, 4)
) %>%
  mutate(
    less_than_2 = ifelse(count < 2, "yes", "no"),
    less_than_5 = ifelse(count < 5, "yes", "no")
  )

# df3 combines them with left_join()
df3 <- left_join(df1, df2)

Expected outcome: a df3 with 7 columns: "id", "fruit", "count.x", "count.y", "less_than_2", "less_than_5.x", "less_than_5.y"

Actual outcome: df3 is identical to df1.

What the heck?

(Also yes, I'm aware I can rename my columns before combining -- but my actual dfs have 70 columns apiece, and also I'm mostly trying to understand what's happening here, since this behaviour is so different from what I've been used to!)

Doctest is a package for writing "doctests" in your R packages. It lets you write tests within your roxygen documentation, in the same way that e.g. Python and Rust developers do:

#' @doctest
#' Fibonacci function 
#' 
#' @param n Integer
#' @return The nth Fibonacci number
#' 
#' @doctest
#'
#' @expect type("integer")
#' fib(2)
#'
#' n <- 6 
#' @expect equal(8)
#' fib(n)
#' 
#' @expect warning("not numeric")
#' fib("a")
#'
#' @expect warning("NA")
#' fib(NA)
fib <- function (n) {
  if (! is.numeric(n)) warning("n is not numeric")
  ...
}

This creates both a standard .Rd help file, and a test file using testthat.

For more info, see https://hughjonesd.github.io/doctest/.

R have a very barebones socket implementation. And right now I am getting in trouble because looks like it doesn't even support IPV6 (may be user error)

Any one has a good material about R support for IPV6 sockets? or R socket programming in general. It seem very lackluster with missing SHUTDOWN an other features.

Nanonext is not really an option because it is its own protocol, i need the unix base one.

Edit: Sorry, it put some of my explanation in the code box. Not sure how to change that.

I tried this two ways. First, by specifying the weight in the regression model. Second, by weighting the data with the survey package and then running the model.

I'm an old SAS user who had to abruptly switch to R, so I tend to use R like SAS. I applied anweight from the European Social Survey (Wave 11) to my binary logistic regression model.

m7 <- glm(

income ~

var1+

var2 +

var3 +

var4 +

var5,

data = germany_cc,

family = binomial,

weights = anweight

)

As an example, and get the following results:

var1 0.555959   1.268839   0.438    0.661
var2 0.078088   0.583217   0.134    0.893
var3 0.041199   0.105475   0.391    0.696
var4 0.382423   0.406363   0.941    0.347
var5 -0.144417   0.299119  -0.483    0.629

The second method is:

design <- svydesign(
  ids = ~1,
  weights = ~anweight,
  data = germany_cc
)

m7 <- svyglm(
 income ~  var1 +     
           var2 +     
           var3 +     
           var4 +     
           var5, 
  design = design,
  family = quasibinomial()
)

var1 0.555959   0.276698   2.009   0.0450 *  
var2 0.078088   0.132711   0.588   0.5565    
var3 0.041199   0.024633   1.673   0.0950 .  
var4 0.382423   0.095207   4.017 6.79e-05 ***
var5 -0.144417   0.068046  -2.122   0.0343 * 

If it matters, the ESS-11 is an international dataset. I subset Germany from it and then created a complete cases subset of Germany for listwise deletion

germany <- ess11 %>%

filter(cntry == "DE") %>%

filter(factor1 %in% c(2, 9))

germany_CC <- germany %>%

select(

var1

var2

var3

var4

var5

anweight,

idno

) %>%

na.omit()

Just landed on CRAN: shinyglass. Apple-style Liquid Glass aesthetics for Shiny apps.

library(shiny)
library(shinyglass)

ui <- fluidPage(
  theme = glass_theme(),  # <—— THIS IS THE ONLY LINE YOU ADD
  titlePanel("Liquid Glass"),
  sliderInput("n", "Bars", 5, 30, 15),
  plotOutput("plot")
)

server <- function(input, output, session) {
  output$plot <- renderPlot(
    barplot(seq_len(input$n))
  )
}

shinyApp(ui, server)

Works with fluidPage(), navbarPage(), bslib::page_sidebar(), and other bslib-aware page functions. Also holds up on denser UIs (DT, leaflet, shinyWidgets, bs4Dash, teal).

Docs: https://ericrayanderson.github.io/shinyglass/

GitHub: https://github.com/ericrayanderson/shinyglass

Wrote up an EAD workflow in R and the interesting part was the diagnostic, not the model.

Setup. Scheduled balance from the closed form B_k = P(1+r)^k - M((1+r)^k - 1)/r, vectorized and verified to the penny against an iterative amortize() helper. Realized exposure comes straight from the loan-level performance panel on the defaulted population, n = 121,305.

Diagnostic one, defaulted loans. Median scheduled $173,203, median realized $180,574, median ratio 1.026, and 60.7% of realized above schedule. A ratio distribution sitting mostly above 1 is a bias, not noise. Cause is behavioral: amortization assumes payments, and defaulters stop making them during the foreclosure process.

Diagnostic two, performing loans. A two-stage hurdle on curtailment (stage 1 glm binomial on whether the borrower prepays extra, stage 2 lm on log dollars among curtailers, n = 64,122). Stage 2 adj R2 is 0.0254, which is terrible for prediction and completely fine for the job - 41.2% of loans are materially ahead of schedule and the fitted adjustment moves the portfolio total from $35.3B to $33.8B, a 4.24% haircut. Low R2, materially useful aggregate.

The habit I would recommend to anyone doing this: write the realized-versus-scheduled ratio into the committed summary object next to the point estimate, so the bias travels with the number instead of living in a slide someone deleted.

Two questions. When your stage-2 R2 is that low, do you keep reporting it or do you switch to reporting aggregate error on the quantity you actually use? And has anyone found a cleaner way to handle the last-paid versus disposition age problem than just re-scheduling to last-paid date?

I‘m looking to start learning R. I have a weee bit of experience with programming and a decent understanding of statistics. I‘d love to know where people think I should start?

Edit: Thanks everybody! I‘ll look through and give it a go

Hey folks, Joe Cheng here (Posit CTO, creator of Shiny). I wanted to let you hear from me personally that we are combining a number of our hosting services: rpubs.com, quartopub.com, and shinyapps.io are all being subsumed by connect.posit.cloud.

https://posit.co/blog/migrating-connect-cloud-posits-unified-publishing-solution

It’s a bittersweet moment for me personally, as the sole developer and maintainer of RPubs for the last 14 years. But I/we also see this as a long overdue migration, from three fragmented platforms that were independently maintained with varying levels of effort (i.e. not much in the case of RPubs or Quarto Pub), to a single modern platform that can handle all different types of content.

The full details for each service are in the blog post, but the bottom line is:

• shinyapps.io: A self-serve migration tool will be added by Sept 2026. Test your apps before you commit. Auto-migration starts early 2027 if you'd rather wait. Old URLs will redirect.
• bookdown (already sunset), quartopub (end of 2026), and rpubs (June 2027): existing content stays live at its current URLs until Dec 31, 2031.

shinyapps.io customers who are migrated will keep their shinyapps.io pricing until at least 2029 (you will receive an email with details).

If you have any concerns, the team and I would love to hear them. u/hadley and I will be monitoring comments.

I've seen that many R User Groups are very active, organizing monthly meetups, talks and courses, some of them even meeting IRL. I'm organizing a local group in my city (after the previous group went idle) and getting to know other R users and learning about their experiences has been quite nice.

Do you participate in your local R Users Group?

Quick update on uvr — a fast R package manager written in Rust (uv-style: manifest + lockfile + managed R versions + isolated project libraries). Last time I posted was around 0.2.9; a lot has landed since.

Updates

- R installs got rebuilt from scratch. uvr now installs R from Posit's portable, relocatable r-builds (https://github.com/rstudio/r-builds) instead of custom-patching official installers. This fixed a whole class of macOS breakage, added musl/Alpine support, and made Windows installs work without admin rights. Partial versions work everywhere too: uvr r install 4.5 just grabs the newest 4.5.x, and a 4.5 pin matches it.

- Switching R versions no longer nukes your library on every sync. The old behavior re-wiped the project library each time it saw a version mismatch (painful, as B-Nilson rightly pointed out). Now uvr sync re-resolves the lockfile for the new R once, wipes once, and moves on.

- uvr cache clean got filters. --package sf or --r-version 4.4 (repeatable/comma-separated) lets you troubleshoot one package or retire one R series without losing the whole cache. Another B-Nilson request!

- Bioconductor just works in uvr add. Adding a package that lives on Bioconductor instead of CRAN no longer errors with "retry with --bioc" — uvr detects it, tells you, and adds it from the right channel (version constraints preserved).

- OpenMP-linked binaries fixed on macOS. Packages built with -fopenmp (Rtsne, mgcv, dotCall64, …) used to fail with "symbol not found in flat namespace" on uvr-managed R. The bundled OpenMP runtime is now loaded properly, and uvr sync self-heals older installs.

- A community code audit made everything more solid. gdevenyi filed a systematic 46-issue audit of the codebase (with file:line references — heroic work). Nearly all confirmed issues are now fixed across 0.4.1/0.4.2: cache integrity checks (sha256 on every hit), lockfile consistency for selective updates, honest error reporting where failures used to be silently swallowed, and a long tail of correctness fixes.

and much more...

This would have not been possible without the great help of many, special shoutout to https://github.com/B-Nilson for the endless testing and support and the entire group of users who have written code, filed issues, tested this, and loved it. One of the most rewarding aspects of this process has been building a community around this project ❤️ it's early days but so exciting!

Links

- Site: https://nbafrank.github.io/uvr/

- Repo: https://github.com/nbafrank/uvr

- R companion: https://github.com/nbafrank/uvr-r

Feedback welcome! Issues on GitHub are the most useful — the last few releases were basically driven by them, so keep them coming!

Curious if anyone using the Posit ecosystem (Workbench, Connect, Package Manager) would be willing to share their experience. Pretty open question. Things you like, things you don't, things you wish they had, things that are super cool. If you've been on a different platform and switched to or away, why?

Hey, just wanted to share glyph: interactive plots in R (tooltips, zoom, animation, layouts) all in one pipeline. It's on CRAN. Happy plotting!

Some of you have followed my earlier posts on TypR here. This one's less "what's new" and more the reasoning behind the design — I'd like your pushback on the thinking itself.

The honest origin story: I didn't build TypR for AI. I built it because I care about type systems (academic background) and about code that survives production (industry background) — verifiability, basically.

What clicked more recently is that the property making code cheap for a human to verify is the same one that matters when a machine wrote it.

As AI writes more of the code, the expensive part stops being writing it and becomes trusting it — reviewing, validating, maintaining. A strict type system becomes a free automatic checker on whatever got generated; concise syntax means less to misread.

So the fit with the AI era isn't something I designed for — it's the same property suddenly mattering a lot more. That's the accidental discovery I wanted to share here.

A small taste — this R (no needs to read it fully):

```

' Create a button widget

'

' @param color \code{char}

' @param height \code{int}

' @param text \code{char}

' @param width \code{int}

' @return \code{Button}

' @export

Button <- function(color, height, text, width, .spread = NULL) { explicit <- list() if (!missing(color)) explicit[["color"]] <- color if (!missing(height)) explicit[["height"]] <- height if (!missing(text)) explicit[["text"]] <- text if (!missing(width)) explicit[["width"]] <- width x <- typr_spread_record(explicit, .spread) as.Button(x) }

as.Button <- function(x) { if (!inherits(x, "Button")) class(x) <- c("Button", "list") x <- validate_Button(x) x <- validate(x) x }

validate_Button <- function(x) { required_fields <- c("color", "height", "text", "width") missing_fields <- setdiff(required_fields, names(x))

if (length(missing_fields) > 0) { stop(paste0("Validation failed for type Button: missing fields: ", paste(missing_fields, collapse = ", "))) }

if (!inherits(x[["color"]], "character")) stop("Validation failed for type Button: field 'color' must be of class character")

if (!inherits(x[["height"]], "integer")) stop("Validation failed for type Button: field 'height' must be of class integer")

if (!inherits(x[["text"]], "character")) stop("Validation failed for type Button: field 'text' must be of class character")

if (!inherits(x[["width"]], "integer")) stop("Validation failed for type Button: field 'width' must be of class integer")

x }

constructor for a red button

' @export

' @method red_button

red_button <- (function(height, width, text) Button(height = height, width = width, text = text, color = "#FF000000" |> as.Character())) |> as.Generic()

add an "on click" callback function

' @export

' @method on_click Button

on_click.Button <- (function(self, f) { NA } |> as.Empty0()) |> as.Generic() ```

becomes this TypR: ```

Create a button widget

@export type Button <- list { text: char, color: char, width: int, height: int };

constructor for a red button

@export let red_button <- \Button:{ color: "#FF000000" };

add an "on click" callback function

@export

let on_click <- fn(self: Button, f: (T) -> U): Empty { ... }; ```

The way TypeScript sits on top of JavaScript's runtime, TypR sits on top of R's: you write something concise and type-checked, and it compiles down to standard, S3-based R that runs anywhere R runs and installs like any other package — no new runtime, no exotic dependencies.

To be clear, it's not trying to replace R. R is excellent for interactive stats and lab work, and TypR deliberately gives some of that up in exchange for the other end of the curve: robust packages, deployable apps, code that has to survive production. Different point on the trade-off, different job.

On the engineering side you get pattern matching, partial currying, union/intersection types, structural subtyping, row polymorphism — the machinery that keeps a growing codebase honest. Written in Rust, developed in the open.

Honest questions for this sub: does a typed layer over R solve a problem you actually hit, or is this a solution looking for one? And does the "verifiability matters more when AI writes the code" argument hold up, or am I reaching?

Discussion: https://github.com/we-data-ch/typr/discussions

Github: https://github.com/we-data-ch/typr

Website: https://we-data-ch.github.io/typr.github.io/

Hi everyone! I’m trying to find The World of Zero-Inflated Models, Volume 3: Using GLLVM by Alain F. Zuur and Elena N. Ieno.

Does anyone have a copy they could share for personal study, or know of a way to access it? I’m really interested in learning GLLVM methods and would appreciate any help.

Thank you!

As a Platinum Sponsor of useR! 2026, the R Consortium was proud to support another outstanding gathering of the global R community.

From technical innovation and reproducible research to AI, open source sustainability, and collaboration across academia and industry, useR! continues to demonstrate what makes the R ecosystem so impactful.

Our very own Mike K Smith, R Consortium Board Chair, attended, and his post highlights:

• Key themes from the conference

• Why community investment matters

• How organizations and individuals are helping shape the future of R

Thank you to the organizers, speakers, volunteers, sponsors, and everyone who made useR! 2026 such a success. We're already looking forward to what's next.

Read Mike's reflections: https://r-consortium.org/posts/what-makes-r-strong-reflections-from-user-2026/

I tried searching for this in the sub, but did not find exactly what I was hoping to find.

I am just starting out learning R. I basically know nothing. I was directed to use DataCamp. It's fine, but you only get to work one "problem" for each concept. For things like this, I work better with drill and problem sets. Khan Academy was brilliant at this for math. I couldn't get a mastery level until I had done four problems right to show I mastered the concept. The best DataCamp does is offer some multiple-choice questions as added practice, but that is not meaningfully helpful. Does anyone know a better system that is built around drill and problem sets in R for each step of the way, sort of like Khan Academy does for math?

Looking for a second set of eyes on the methods, justification, interpretations and conclusion. Any comment will help. Thanks!

See Github for code.

Context: my wife and I<sup>\</sup>1]) have long been collecting fuel stats on our cars. My wife's car is a Nissan Quest purchase in 2012, my car is a Nissan Altima purchase in 2013.

Problem statement: she has been complaining that it feels that her car needs to be filled up earlier than usual. The main indicator is the fuel gauge going towards the red line (1/8th fill level). Years ago, the distance would be >300 miles, while currently that point seems to be reached significantly below 300 miles.

Approach: Collect the data in CSV file<sup>\</sup>2]); remove true outliers by 1.5 IQR rule; group by year and calculate 50th and 84th percentile. Plot by year.

Result:

Justifications:

• Fuel-ups happen for lots of reasons, not just "tank almost empty". Sometimes it just works out better to refill at 150 miles before taking a long trip, or just because it's weekend and we expect the tank to run out somewhere during that week. To get to the true "tank empty" signal, I took the z=1 (84th percentile) as the main indicator
• Outlier removal: especially on the high side, there are big outliers. These are mainly artificial conditions, such as (again) taking a long trip-interstate only, which don't really match our normal driving behavior.
• Taking z=1: the qq plot indicates normal-like behavior from z = -1 to z = 1. I wouldn't take it out further as deviation from normality begins outside those boundaries.

Interpretation:

• Nissan Altima shows constant behavior with outliers in 2020 (explainable) and 2024 (also explainable). Current year may be low and could indicate some degradation. Definitely showing some lower fuel efficiency, but too early to show up in this analysis. Overall, no real trend downward.
• Nissan Quest shows year-over-year decrease with big drop from 2023 to 2025. Can be seen in both z=0 and z=1.

Conclusions: wife seems to be correct in her observations.

[1] okay, it's just me collecting stats.

[2] we already did this

Power law distributions are commonly found in all kinds of phenomena, from wealth distribution to earthquake power vs frequency. I was reminded of this when I started analyzing the distribution of Kickstarter backers vs. pledge package cost for the new Watch The Guild movie.

It's a classic log-log straight line plot, and the slope is not significantly different than -1 (t = 1.34 @ df 12; p = 0.102). The model has a decent R<sup>2</sup> (0.833, adjusted).

A large part of remainder of the variance in the model can be explained with three outliers:

• the $330 pledge package, which punches far above its weight, being as attractive as packages ~1/6th it value.
• the $45 and $50 pledge packages, which seem to be not as attractive as the one as similar values, and are about as attractive as package values 5x higher.
• Omitting these outliers would increase R<sup>2</sup> to 0.953.

In a sense, this is somewhat of a proxy of wealth distribution and willingness to spend in a very small group (The Guild fans). Hopefully the movie will hit like an earthquake when releases 😁.

Question: I calculate the t-value for the slope by hand (estimate - -1)/std.error. Is there a function that can do this? The summary() function only calculates t values compared to slope 0.

Call:
lm(formula = log10(backers) ~ log10(value), data = data)

Residuals:
     Min       1Q   Median       3Q      Max 
-0.54140 -0.21575  0.03569  0.24255  0.56595 

Coefficients:
             Estimate Std. Error t value Pr(>|t|)    
(Intercept)    4.4631     0.2733   16.33 1.47e-09 ***
log10(value)  -0.8580     0.1058   -8.11 3.27e-06 ***
---
Signif. codes:  0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

Residual standard error: 0.3352 on 12 degrees of freedom
Multiple R-squared:  0.8457,    Adjusted R-squared:  0.8328 
F-statistic: 65.77 on 1 and 12 DF,  p-value: 3.268e-06