Skip to content

Enhance TabPFNRegressor to handle constant target values #263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

anuragg1209
Copy link
Contributor

@anuragg1209 anuragg1209 commented Apr 5, 2025

Hi @noahho,

Fix #246.

New Tests:

  • Added a new test test_constant_target to verify that the TabPFNRegressor correctly predicts a constant value when the target y is constant.

Copy link
Collaborator

@LeoGrin LeoGrin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM!

logits=torch.full((X.shape[0], 1), self.constant_value_) I think the logits shouldn't be equal to self.constant_value_, right? I'm not sure what they should be equal to though, perhaps all ones or something else uniform? (I guess self.constant_value_ could also work then, but might be confusing).

@anuragg1209
Copy link
Contributor Author

Thanks, LGTM!

logits=torch.full((X.shape[0], 1), self.constant_value_) I think the logits shouldn't be equal to self.constant_value_, right? I'm not sure what they should be equal to though, perhaps all ones or something else uniform? (I guess self.constant_value_ could also work then, but might be confusing).

Thanks for the review @LeoGrin!
I have made a few changes. Now, the logits are set to 0, and we also have a constant_criterion for constant targets. This aligns better with the code semantics.

@LeoGrin
Copy link
Collaborator

LeoGrin commented Apr 8, 2025

Thanks @anuragg1209!
If we change the criterion like that (and I agree it's better), it might be simpler to just change self.renormalized_criterion_ in fit, to the constant criterion you've defined here. This should directly make the output mean, mode and median constant. The quantile wouldn't be exactly the same that what you have here, not sure if it's ok or if we want to hardcode it. WDYT?

@anuragg1209
Copy link
Contributor Author

Thanks @anuragg1209! If we change the criterion like that (and I agree it's better), it might be simpler to just change self.renormalized_criterion_ in fit, to the constant criterion you've defined here. This should directly make the output mean, mode and median constant. The quantile wouldn't be exactly the same that what you have here, not sure if it's ok or if we want to hardcode it. WDYT?

Hi @LeoGrin, I like the idea of changing the self.renormalized_criterion_ in fit, to the constant criterion. It makes more sense now. Also, the mean, mode, median and quantiles all remains constant so we have everything working as intended.

@LeoGrin
Copy link
Collaborator

LeoGrin commented Apr 8, 2025

Thanks @anuragg1209! Do we still need to set the constant mean, mode etc manually now? I would have guessed that it would automatically work with the new criterion defined in fit (except for the quantiles, which would be a bit different, which is maybe fine). But I'm not sure.

@anuragg1209
Copy link
Contributor Author

Thanks @anuragg1209! Do we still need to set the constant mean, mode etc manually now? I would have guessed that it would automatically work with the new criterion defined in fit (except for the quantiles, which would be a bit different, which is maybe fine). But I'm not sure.

The reason we are setting the mean, mode, etc. manually is because if we use a criterion-based approach, even with tight borders, numerical operations introduce tiny floating point differences from the constant value. The current approach of setting manually also works fine as we are only dealing with the edge case of constant y, but if we want to completely remove setting mean, mode, etc, manually, then we have to introduce a tolerance-based test.

@LeoGrin
Copy link
Collaborator

LeoGrin commented Apr 14, 2025

Thanks @anuragg1209! In this case maybe it actually makes more sense to put most things in predict for clarity, sorry for the change. Otherwise LGTM but I wondering if there is an issue if you call fit on a constant dataset, and then again on a new dataset. Wouldn't is_constant_target stay True for the 2nd dataset?

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

Successfully merging this pull request may close these issues.

TabPFNRegressor fails on constant input data
2 participants