FAQ and Troubleshooting

Short practical answers and routing for common np, npRmpi, and crs questions.
Keywords

FAQ, troubleshooting, np, npRmpi, crs, install, factor, MPI

This page keeps the useful question-and-answer material and drops the old habit of duplicating changelog text inside the FAQ.

Two support pages now carry the more detailed practical guidance:

Fast routes

If you need… Start here
the smallest runnable scripts Quickstarts
density, conditional-density, distribution, or quantile examples Density, Distribution, Quantiles
classification or conditional-mode examples Classification and Modes
plotting, predictions, or interval examples Plotting and Intervals
npRmpi install and launch guidance MPI and Large Data
factors, ordered variables, and formula traps Data Preparation and Variable Types
runtime, memory, and scaling advice Runtime, Memory, and Scaling
function-name lookup Reference and Function Lookup

Which package should I start with?

Start with np unless you already know that you need MPI or spline methods.

  • Use np for core kernel regression, density, distribution, and testing on one machine.
  • Use npRmpi when the same workflow becomes large or slow enough that MPI is warranted.
  • Use crs when regression splines or spline-specific constraints are the natural tool.

The short chooser lives on Choose a Package.

I am new to R. Where should I begin?

Begin with Install and Get Started. Then run one small example from Quickstarts before worrying about the longer scripts.

Good general resources are:

How do I keep my installed packages current?

This remains a sensible command:

## Refresh installed packages when you want a conservative update sweep
update.packages(checkBuilt = TRUE, ask = FALSE)

What should I check when moving to 0.80-1?

If you are updating from 0.70-5, the main user-facing migrations in np and npRmpi are compact:

  • use B rather than boot.num in npcmstest(), npqcmstest(), npdeneqtest(), npdeptest(), npsdeptest(), npsigtest(), npsymtest(), npunitest(), and npindex(); the existing $boot.num result field is unchanged,
  • replace underscore plot controls with their dotted spellings, including data.overlay, data.rug, factor.boxplot, boxplot.outliers, coef.index, common.scale, proper.method, proper.control, boot.control, grid.control, and render.control,
  • request fit-time uncertainty with se = TRUE; the default is FALSE for npreg(), npscoef(), nplsqreg(), npudens(), npudist(), npcdens(), npcdist(), npplreg(), npqreg(), npconmode(), and npcopula(),
  • treat npindex() as the deliberate exception: it defaults to se = TRUE, se.type = "asymptotic"; use se = FALSE for a point-only fit or se.type = "bootstrap" for bootstrap fitted-value and gradient errors,
  • use se.fit = TRUE for prediction uncertainty and gradients(object, se = TRUE) for stored gradient standard errors; public extractors do not perform a hidden refit when the requested state is absent,
  • use gradient.order for derivative order; the gradient_order alias is retired,
  • keep using method-valued plot controls such as errors = "asymptotic" and errors = "bootstrap"; only the former Boolean estimator argument named errors has been retired,
  • replace the removed experimental nptgauss() and truncated-Gaussian kernel with a supported Gaussian, Epanechnikov, or uniform route.

Newly created bandwidth objects retain their prepared training sample, effective missing-data policy, and formula-subset provenance. This makes ordinary no-search refits, plots, predictions, and saveRDS()/readRDS() workflows much less dependent on objects in the original calling environment. Objects created by older package versions do not contain that state and may still require their original data bindings or an explicit data = argument.

For native bandwidth-object workflows, named newdata columns are matched to the retained variable names and may be supplied in a different order; extra columns are ignored, while missing, duplicate, or ambiguous required columns are rejected. Explicit native evaluation arguments continue to take precedence over standard newdata.

For a fitted vector-tau location-scale quantile model, predict(fit, tau = ...) selects stored quantiles in the requested order without bandwidth selection or recalibration. Unfitted values are rejected; omit tau or use tau = NULL to preserve the original all-quantile result.

Klein–Spady single-index models now support factor predictors through retained R model-matrix contrasts, but their response must be numeric and contain the two values 0 and 1. A factor response is rejected rather than interpreted through its internal codes. For copula plots, choose the probability-grid size with neval when constructing npcopula() or supply u; plot.npcopula() does not accept neval.

The instrumental-regression methods are also substantially more conventional: npregiv() and npregivderiv() now accept formula/data calls, return objects with summary(), fitted(), residuals(), gradients(), and dedicated plot methods, and reject unsupported nearest-neighbour bandwidths early. Their plot controls are now gradients, data.overlay, and data.rug; the experimental plot.data, deriv, and phi switches are retired. npregivderiv() now defaults to local-linear estimation when regtype is omitted, which can change results relative to older calls that relied on the former local-constant behavior. IV evaluation is requested when fitting; post-fit predict() is not currently available for these two np estimators.

Principal estimators and bandwidth selectors now reject unknown named arguments instead of silently accepting them through ..., so a newly exposed spelling error is usually an actionable migration message rather than a numerical failure.

The role of data= is also explicit. Formula calls use data to build their model frame, and supported formula-bearing bandwidth-object refits can replace that data. Native calls instead receive vectors, matrices, or data frames through arguments such as xdat and ydat; where data is not a documented native input, supplying it, including data = NULL, is now an error rather than an ignored argument.

## Formula interface: data supplies the model frame
fit_formula <- npreg(y ~ x, data = mydat)

## Native interface: supply the observation arrays directly
bw_native <- npregbw(xdat = mydat["x"], ydat = mydat$y)
fit_native <- npreg(bws = bw_native)

## with() is another clear native spelling
bw_with <- with(mydat, npregbw(xdat = x, ydat = y))

Some functions genuinely define a native argument named data, including the documented observation-data route for npcopula() and selected test helpers. Follow the individual help page rather than adding data = NULL defensively. Plot methods generally do not accept replacement data; refit first unless the selected plot route explicitly documents that input.

Some corrected edge contracts can also change affected numerical results. These include heterogeneous polynomial-degree fits, positive-degree categorical effects, uniform nearest-neighbour boundary cases, ordered Wang–van Ryzin distribution estimates, explicit fixed-bandwidth bias-corrected plot centers, physical bandwidths recovered when bwscaling = TRUE, and several requested standard-error routes. Corrected deleted-sample beta and bounded-kernel nearest-neighbour criteria may also select different bandwidths and can cost more than the former incorrect criteria. Bootstrap tests count ties as at least as extreme, and replication-ordered plot-bootstrap random streams can change historical seeded bands while making current results independent of chunk size and MPI worker count. These are targeted corrections rather than a change to unaffected estimators.

npdeneqtest() now selects one common pooled bandwidth and supports fixed, unnormalized Gaussian, Epanechnikov, and uniform kernels. It rejects nearest-neighbour, beta, boundary-normalized, and active ordered RLY configurations rather than applying a different test silently.

Why can an external evaluation row return NA?

If every computed explanatory-kernel weight is zero, or a required normalization is non-finite, the affected regression, conditional, quantile/mode, single-index, smooth-coefficient, and hat routes return NA for the external row and issue one consolidated notice. Defined rows in the same call remain available.

This most often means that a compact-support evaluation point lies too far from the training support for the selected bandwidth. Check the evaluation grid and the fitted bandwidth object before deciding whether a larger bandwidth or a different supported kernel is scientifically appropriate. The package does not invent a numerical floor or a fabricated estimate for that row.

Where is the gentlest introduction to the packages?

Use the package vignettes and then the gallery pages.

## Start with the installed package vignettes
vignette("np_getting_started", package = "np")
vignette("np_entropy_tests", package = "np")
vignette("crs_getting_started", package = "crs")
vignette("npRmpi_getting_started", package = "npRmpi")

For a shorter web route, start with:

How do I find functions, examples, and demos quickly?

For package help:

## Use help lookups and runnable examples directly from the installed packages
library(help = "np")
library(help = "crs")
?npreg
?crs

For runnable examples:

## Run the built-in examples and demos from the installed packages
example(npreg)
example(crs)
demo(package = "crs")

For website-first routing:

Where do I find runnable examples?

How should I prepare mixed data?

The class of each variable matters. Continuous variables can remain numeric, but unordered categorical variables should be factors and ordered categorical variables should be ordered factors when that distinction is meaningful.

## Build a mixed-data frame with explicit variable classes
mydat <- data.frame(y = rnorm(200),
  x_cont = runif(200),
  x_unordered = factor(sample(c("a", "b", "c"), 200, replace = TRUE)),
  x_ordered = ordered(sample(1:4, 200, replace = TRUE)))

This is not just bookkeeping. In np, the variable class affects the weighting rule used by the estimator.

For a more deliberate checklist, see Data Preparation and Variable Types.

Does formula syntax imply a linear-additive model?

No. In np, a formula such as

## Formula syntax still just names the response and covariates
y ~ x1 + x2 + x3

simply tells the function which variable is the response and which are the covariates. It does not mean that you are fitting an ordinary linear-additive model. The formula interface is a convenient way to specify the variables, not a commitment to parametric structure.

Why should I create an explicit bandwidth object?

Because in np the bandwidth object is often the key object in the workflow.

## Create the bandwidth object explicitly before fitting
bw <- npregbw(y ~ x1 + x2, data = mydat)
summary(bw)
fit <- npreg(bws = bw)

Working explicitly this way makes it easier to inspect the chosen bandwidths, reuse them, and avoid unnecessary recomputation.

If you instead begin with a single high-level estimator call, the fitted object retains its selected bandwidth object. Reuse that $bws component when you later want another option without repeating the search:

## Search and fit first; later request gradients without searching again
fit <- npreg(y ~ x1 + x2, data = mydat)
fit_grad <- npreg(bws = fit$bws, gradients = TRUE)

This reruns only the fitting work needed for the new request, not bandwidth optimization.

For the broader runtime side of this issue, see Runtime, Memory, and Scaling.

Where do I find the changelog?

The FAQ should not duplicate changelog text.

Use the package page on CRAN and the package repo NEWS.md / release notes instead. The point is to keep one canonical record of changes rather than two or three drifting copies.

Some older examples use attach(). Should I?

Older scripts and vignettes sometimes use attach() because that was a common style at the time. For modern work, it is usually better to avoid attach() and instead use:

  • explicit data = arguments,
  • explicit data-frame references such as mydat$x,
  • or a short preprocessing step that creates a clean data frame.

That keeps variable scope clearer and reduces accidental name collisions.

Why can bandwidth selection take a while?

Because many of these methods are doing real search and resampling work rather than evaluating a closed-form formula once.

Practical advice:

  1. start with a small example,
  2. confirm the workflow in serial first,
  3. move to npRmpi only when the serial workflow is the right one but too slow for the job at hand.

The fuller version of that advice now lives on Runtime, Memory, and Scaling.

I have data from Stata, SAS, SPSS, or elsewhere. Can I still use these packages?

Yes. The important point is not the original file format but the data frame you hand to the modeling function once the data are in R. After import, make sure the variable classes are correct before fitting models, especially for factors and ordered factors.

How do I cite the packages?

Use citation() from inside R and see Books, Papers, and Citation for the package papers and books.

## Ask the installed packages for their current citation records
citation("np")
citation("npRmpi")
citation("crs")

I am using npRmpi and see npRmpi auto-dispatch requires an active MPI slave pool

That means there is no active MPI session.

  • For interactive work, call npRmpi.init(nslaves = 1) first.
  • For mpiexec jobs, initialize with npRmpi.init(mode = "attach", ...) near the top of the script.

On current package sources, Windows belongs in the second branch rather than the first.

The detailed route is on MPI and Large Data.

I am using npRmpi and see could not find function "mpi.bcast.cmd"

This usually means a manual-broadcast/profile script started without the required profile startup.

Check the following:

  1. R_PROFILE_USER points to the intended profile file,
  2. R_PROFILE is cleared,
  3. the command is not using R CMD BATCH --vanilla,
  4. the effective launch command really includes -env R_PROFILE_USER <path>.

I need examples for npRmpi on larger or more complex systems

Use MPI and Large Data. That page now treats:

  • session / spawn as the default instructional path,
  • attach as the normal mpiexec autodispatch route,
  • profile / manual-broadcast as the advanced route, and often the right one for heterogeneous clusters.

Where should I look next?

Can crs recover something as simple as linear regression?

Yes. Spline methods include simpler structures as special cases when the basis is restricted appropriately. A short illustration now appears on Splines.

I am using crs and the search is slow or memory hungry

That usually means the search space is simply large, not that the fit is broken.

The first levers to inspect are:

  • cv.df.min
  • degree.max
  • segments.max
  • basis
  • complexity

The practical route now lives on Spline Search and Tuning, with the broader ecosystem version on Runtime, Memory, and Scaling.

I want a smoother spline, fixed degree, or the selected knots

Those are all legitimate practical questions, and they are better handled directly than by pretending the cross-validated answer should have been different.

See Spline Search and Tuning for:

  • imposing a minimum spline degree,
  • holding degree fixed and searching over knots,
  • retrieving knot locations from the fitted model,
  • and the linear-regression special case.

Legacy FAQ PDFs

The old FAQs still contain useful material, but they also contain obsolete changelog duplication and older presentation choices.

  • Legacy np FAQ PDF: no longer hosted in the current CRAN vignette set; use the current np vignettes on CRAN.
  • Legacy crs FAQ PDF: no longer hosted in the current CRAN vignette set; use the current crs vignettes on CRAN.
Back to top