so I am trying to vizualize the prediction of an QDA-learner using the mlr3viz-package in R. The vizualisation (via plot_learner_prediction) works fine, however everytime I try to expand the range of the predictions via the expand_range attribute nothing happens.
pl = plot_learner_prediction(learner, task, expand_range = 3)
Nothing happens when I add or change the expand_range argument. Does anyone know how to handle this argument? I had a look into the documentation https://mlr3viz.mlr-org.com/reference/plot_learner_prediction.html but it doesn't really help me.
Thanks a lot already!
Related
This question may seem basic but this has bothered me quite a while. The help document for many functions has ... as one of its argument, but somehow I can never get my head around this ... thing.
For example, suppose I have created a model say model_xgboost and want to make a prediction based on a dataset say data_tbl using the predict() function, and I want to know the syntax. So I look at its help document which says:
?predict
**Usage**
predict (object, ...)
**Arguments**
object a model object for which prediction is desired.
... additional arguments affecting the predictions produced.
To me the syntax and its examples didn't really enlighten me as I still have no idea what the valid syntax/arguments are for the function. In an online course it uses something like below, which works:
data_tbl %>%
predict(model_xgboost, new_data = .)
However, looking across the help doc I cannot find the new_data argument. Instead it mentioned newdata argument in its Details section, which actually didn't work if I displace the new_data = . with newdata = .:
Error in `check_pred_type_dots()`:
! Did you mean to use `new_data` instead of `newdata`?
My questions are:
How do I know exactly what argument(s) / syntax can be used for a function like this?
Why new_data but not newdata in this example?
I might be missing something here, but is there any reference/resource about how to use/interpret a help document, in plain English? (a lot of document, including R help file seem just give a brief sentence like "additional arguments affecting the predictions produced" etc)
#CarlWitthoft's answer is good, I want to add a little bit of nuance about this particular function. The reason the help page for ?predict is so vague is an unfortunate consequence of the fact that predict() is a generic method in R: that is, it's a function that can be applied to a variety of different object types, using slightly different (but appropriate) methods in each case. As such, the ?predict help page only lists object (which is required as the first argument in all methods) and ..., because different predict methods could take very different arguments/options.
If you call methods("predict") in a clean R session (before loading any additional packages) you'll see a list of 16 methods that base R knows about. After loading library("tidymodels"), the list expands to 69 methods. I don't know what class your object is (class("model_xgboost")), but assuming that it's of class model_fit, we look at ?predict.model_fit to see
predict(object, new_data, type = NULL, opts = list(), ...)
This tells us that we need to call the new data new_data (and, reading a bit farther down, that it needs to be "A rectangular data object, such as a data frame")
The help page for predict says
Most prediction methods which are similar to those for linear
models have an argument ‘newdata’ specifying the first place to
look for explanatory variables to be used for prediction
(emphasis added). I don't know why the parsnip authors (the predict.model_fit method comes from the parsnip package) decided to use new_data rather than newdata, presumably in line with the tidyverse style guide, which says
Use underscores (_) (so called snake case) to separate words within a name.
In my opinion this might have been a mistake, but you can see that the parsnip/tidymodels authors have realized that people are likely to make this mistake and added an informative warning, as shown in your example and noted e.g. here
Among other things, the existence of ... in a function definition means you can enter any arguments (values, functions, etc) you want to. There are some cases where the main function does not even use the ... but passes them to functions called inside the main function. Simple example:
foo <- function(x,...){
y <- x^2
plot(x,y,...)
}
I know of functions which accept a function as an input argument, at which point the items to include via ... are specific to the selected input function name.
I am trying to plot a function in Julia, but keep getting errors. I don't understand what is wrong. The input and output of $\varphi$ is a scalar. I've used x=1530:1545 and still get an error-- can anyone enlighten me? I am very confused.
I am using Julia 0.7.
EDIT:
I got it to work with a slight modification--I changed
x = 1530:1545
added the following two lines
y = t.(x)
plot(x,y)
Why did I have to do this though?
This feature is currently not available in PyPlots.jl, if you would like to have it in the future, your best bet is to file an issue.
However, you can get that functionality via Plots.jl and using PyPlot as a backend.
It would look like this (I'll take a simpler function):
using Plots
pyplot()
start_point = 0
end_point = 10
plot_range = start_point:end_point
plot(sqrt,plot_range) # if you want the function exactly at 0,1,2,3...
plot(plot_range,sqrt) # works the same
plot(sqrt,start_point,end_point) # automatically chooses the interior points
THis is probably a very silly question, but how can I check if a function written by myself will work or not?
I'm writing a not very simple function involving many other functions and loops and was wondering if there are any ways to check for errors/bugs, or simply just check if the function will work. Do I just create a simple fake data frame and test on it?
As suggested by other users in the comment, I have added the part of the function that I have written. So basically I have a data frame with good and bad data, and bad data are marked with flags. I want to write a function that allows me to produce plots as usual (with the flag points) when user sets flag.option to 1, and remove the flag points from the plot when user sets flag.option to 0.
AIR.plot <- function(mydata, flag.option) {
if (flag.option == 1) {
par(mfrow(2,1))
conc <- tapply(mydata$CO2, format(mydata$date, "%Y-%m-%d %T"), mean)
dates <- seq(mydata$date[1], mydata$date[nrow(mydata(mydata))], length = nrow(conc))
plot(dates, conc,
type = "p",
col = "blue",
xlab = "day",
ylab = "CO2"), error = function(e) plot.new(type = "n")
barplot(mydata$lines, horiz = TRUE, col = c("red", "blue")) # this is just a small bar plot on the bottom that specifies which sample-taking line (red or blue) is providing the samples
} else if (flag.option == 0) {
# I haven't figured out how to write this part yet but essentially I want to remove all
# of the rows with flags on
}
}
Thanks in advance, I'm not an experienced R user yet so please help me.
Before we (meaning, at my workplace) release any code to our production environment we run through a series of testing procedures to make sure our code behaves the way we want it to. It usually involves several people with different perspectives on the code.
Ideally, such verification should start before you write any code. Some questions you should be able to answer are:
What should the code do?
What inputs should it accept? (including type, ranges, etc)
What should the output look like?
How will it handle missing values?
How will it handle NULL values?
How will it handle zero-length values?
If you prepare a list of requirements and write your documentation before you begin writing any code, the probability of success goes up pretty quickly. Naturally, as you begin writing your code, you may find that your requirements need to be adjusted, or the function arguments need to be modified. That's okay, but document those changes when they happen.
While you are writing your function, use a package like assertthat or checkmate to write as many argument checks as you need in your code. Some of the best, most reliable code where I work consists of about 100 lines of argument checks and 3-4 lines of what the code actually is intended to do. It may seem like overkill, but you prevent a lot of problems from bad inputs that you never intended for users to provide.
When you've finished writing your function, you should at this point have a list of requirements and clearly documented expectations of your arguments. This is where you make use of the testthat package.
Write tests that verify all of the requirements you wrote are met.
Write tests that verify you can no put in unintended inputs and get the results you want.
Write tests that verify you get the output you intended on your test data.
Write tests that test any edge cases you can think of.
It can take a long time to write all of these tests, but once it is done, any further development is easier to check since anything that violates your existing requirements should fail the test.
That being said, I'm really bad at following this process in my own work. I have the tendency to write code, then document what I did. But the best code I've written has been where I've planned it out conceptually, wrote my documentation, coded, and then tested against my documentation.
As #antoine-sac pointed out in the links, some things cannot be checked programmatically; for example, if your function terminates.
Looking at it pragmatically, have a look at the packages assertthat and testthat. assertthat will help you insert checks of results "in between", testthat is for writing proper tests. Yes, the usual way of writing tests is creating a small test example including test data.
Shot in the dark but I cannot get a plot function to work in the CollocInfer package. I am trying to execute the following code:
plotfit.fd(temps, times, DEfd1,nfine=N,
xlab="Time (hours)", ylab="Temperature level (metres)",title="")
I have my code working perfectly up until this point. When I execute I get the following error:
Error in checkDim3(x, y, xdim[id], ydim[id], dNi, subset, xName = xNmi, :
Can NOT subset subscript 1 of DEfd1$coef because some dimnames(subscript 1 of temps)[[xdim=2]] are not found in dimnames(y)[[ydim=2]]; the first one is temps
I've been trying to track down what this means for hours. I ran some pacjkage supplied code and tried to figure it out and couldn't. The documentation for the checkDim3 function is here: http://www.psych.mcgill.ca/misc/fda/downloads/FDAfuns/R/R/checkDims3.R
I looked at the data and the values are consistent, i.e. I solved the ODE I am trying to model and the parameter estimates are correct. Somewhere I made an error in the bookkeeping? Any help appreciated. Or a workaround.
Ha, lesson learned:
dimnames(temps) <- NULL
works. This particular plotting function has tests for the dimnames of inputs.
I have a question about Reference Classes. My question is in the context of an R package I am developing rCharts. It uses reference classes to create interactive plots from R.
Creating a plot involves a series of calls. Here is an example, where a scatterplot is created at first and then a line plot gets added.
p1 <- rPlot(mpg ~ cyl, data = mtcars, type = 'point')
p1$layer(copy_layer = T, type = 'line')
Now, since a Reference Class is like a closure, I was wondering if it was possible to log the calls made. The idea is that if I can log the sequence of calls made, then I can automagically insert the source code used to create a visualization, along with the html.
I was trying to see if I could make use of sys.function or match.call, but am not getting anywhere. If someone can point me to how I can approach this, it would be much appreciated.
As #hadley stated:
calls <<- c(calls, list(match.call()))
Glad that looks to have worked. Let's get this closed. :)