Skip to content

feat(CI): handle multi-part Erdős problems in status check#2327

Open
zond wants to merge 2 commits intogoogle-deepmind:mainfrom
zond:main
Open

feat(CI): handle multi-part Erdős problems in status check#2327
zond wants to merge 2 commits intogoogle-deepmind:mainfrom
zond:main

Conversation

@zond
Copy link
Contributor

@zond zond commented Feb 17, 2026

For problems with no single erdos_{N} theorem (e.g. multi-part problems with erdos_{N}.parts.i, erdos_{N}_cycles, etc.), collect all non-variant theorems and report open if any part is open.

For problems with no single `erdos_{N}` theorem (e.g. multi-part problems
with `erdos_{N}.parts.i`, `erdos_{N}_cycles`, etc.), collect all non-variant
theorems and report open if any part is open.
@mo271
Copy link
Collaborator

mo271 commented Feb 20, 2026

I'd like to have @danielchin's opinion here!
Should we introduce a consistent naming for those parts of a main question that are in the box versus those that variants that are in the additional material below the box?
One we have consistent naming it should be pretty clear when there is a mismatch between "solved" on the website as indicated by Tao's json and our "solved" categories, i.e. "solved" on the website should correspond to all parts in the box are marked research solved (or research formally solved)

@danielchin
Copy link
Contributor

I agree that we probably need to come up with a proper standard and document it in the README since it looks like the naming convention has evolved over time.

I'll call the two potential parts of an Erdos problem: the main part (whatever is in the red or green box) and the additional text (whatever is below the red or green box).

For the additional text, I think this is easy. We just always call it erdos_{N}.variants.{name}.

For the main part, we have to consider all the types of questions we have and whatever future ones T. Bloom might add in the future.

  1. Single questions: This is simple, we just do erdos_{N}.
  2. Multiple part question: We can maintain what we're doing right now with erdos_{N}.parts.i and erdos_{N}.parts.ii. There won't be an actual erdos_{N} in this case.
  3. Estimate question: The common pattern right now is erdos_{N}.lower_bound and erdos_{N}.upper_bound.
  4. Describe/Explain the behavior: I don't believe we have an example of this one yet.

Assuming that we're okay with that naming convention, we can just check for all erdos_{N} that do not contain with variants and if they are all solved (because some parts can be solved, but other parts unsolved, meaning that the website displays them as unsolved), then you can mark it as solved and compare it against the website.

I did previously ask something similar to this in the Zulip chat: #Formal conjectures > Referencing OEIS @ 💬

Yael mentioned that we should replace the . notation with underscores, but I think it's cleaner to keep the ., but just state to not repeat subnames (which I assume that's what Yael is saying).

def is_variant(suffix):
"""Check if a theorem name suffix indicates a variant (not a main part)."""
# ".variants." anywhere in the suffix means it's a variant
return ".variants." in suffix or ".variant." in suffix
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you leave a TODO here (you can assign it to me) to remove anything that's variant. We should just rename everything to variants and have the linter catch anything that's not one of our existing patterns.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fix the naming problem here: #2408

@mo271
Copy link
Collaborator

mo271 commented Feb 22, 2026

Sounds good, @danielchin! We could add this naming convention to a README.md in ./ErdosProblems/ and then do big pull request making sure we adhere to the proposed standard. Do you want to do that or shall somebody else?

@danielchin
Copy link
Contributor

Yup, I can do the write up and then do a massive clean up to ensure standards are being met. Feel free to assign me an issue.

@zond
Copy link
Contributor Author

zond commented Feb 27, 2026

So, do I need to change anything with this PR, or?

@danielchin
Copy link
Contributor

You can drop the condition on .variant. on line 89 since there aren't problems named with that anymore.

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.

3 participants