Extend dcast() to support different fill= values for different columns

Open
#5,990 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
r
Domain
data

Research direction

Start by reading the current dcast() fill handling and the setnafill() entry point, including the existing C logic mentioned in the issue. Define and test named-list fills for multiple value.var columns, including the proposed list(0) semantics and any default behavior. Done means dcast() supports distinct fill values without regressing existing fill= behavior.

Written by the indexing model from the issue text.

Description

reshape

As raised in #5980, this would bring us closer to parity with tidyr::pivot_wider()'s values_fill argument. This seems especially useful for length(value.var) > 1L use cases, when the different value.var can quite reasonably need different fill= values.

We are free to choose our own way for the extended argument to work, but the pivot_wider() approach seems clear enough: when fill is a named list, the names are columns and the elements are values to be filled. I'm not sure if {tidyr} supports a default unnamed entry so that you could do, e.g. fill = list(special = 1, 0) so that most columns are filled with 0, except for one special column. The only trouble is what to do with fill = list(0); I think we need to interpret that as "fill with the length-1 list with entry 0", not as "0 by default for all columns".

PS I also wonder if it wouldn't be easier to just re-use setnafill() to handle the fill= argument of dcast(), rather than the current logic in C which essentially duplicates that.

Dominant language
R
Stars
3.9k
Forks
1.1k
Avg merge
14h 4m
Merged PRs (30d)
4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Rdatatable/data.table

All issues in Rdatatable/data.table

Similar issues

More R issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.