Skip to content
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.

init parameter check_every not work #130

Open
yc19920125 opened this issue Aug 9, 2016 · 3 comments
Open

init parameter check_every not work #130

yc19920125 opened this issue Aug 9, 2016 · 3 comments

Comments

@yc19920125
Copy link

Hi:
I am trying to use the parameter check_every to control my fitting time, but I found it didn't make any differences when I change the init parameter check_every.
So I wonder whether the parameter check_every is useful now?

@jcrudy
Copy link
Collaborator

jcrudy commented Aug 10, 2016

I would say it's not very useful for performance purposes. If you're looking for speed, I would suggest using the use_fast option.

@yc19920125
Copy link
Author

Thanks for your answer!
So here comes a question:
What does the parameter check_every exactly do.
I found the fitting results(both predict accuracy and basis) are always the same when I change the parameter check_every.

@jcrudy
Copy link
Collaborator

jcrudy commented Aug 11, 2016

I think if you set check_every sufficiently high, you should eventually see a worse fit (and maybe a very slight speed up). I think it speaks to the usefulness of check_every that I actually had to look in the code to make sure it's even still implemented. All it does is reduce the number of candidate knot locations during knot search. One reason to do this would be to make sure you don't end up with knots too close together. However, the minspan argument takes care of that in a much nicer way. I think I originally put check_every in in order to duplicate the behavior of the R earth package, which implements minspan the way py-earth implements check_every (or at least that was my understanding at the time). Basically, I'd say there's no good reason to use check_every at this point, unless you want to make your model worse for some reason (testing or something).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants