Skip to content
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

test: Quotient universe levels #1809

Closed

Conversation

Alizter
Copy link
Collaborator

@Alizter Alizter commented Jan 12, 2024

I've added tests to check what the universe levels for quotient are like. Many of them are incorrect in the sense that Quotient takes 3 universe variables, but lemmas about it restrict to 2.

Does it really make sense for Quotient to take 3 levels? There are 2 "real" levels and the third is supposed to be a max of them without restricting the relation between the other two.

@jdchristensen
Copy link
Collaborator

I think it is correct for Quotient to take three universe variables. If it weren't for the Trunc, you could remove the universe it lands it and replace it with max applied to the other two, but since we need to apply Trunc, three is needed and is standard for this kind of construction.

However, I noticed that GraphQuotient@{i j u} doesn't enforce that j <= u. I think we should change its universe annotation to @{i j u | i <= u, j <= u} (and we should do the same for Quotient as a form of documentation/testing). Unless I'm confused, a HIT needs to land in a universe that contains both the point constructors and the path constructors. I wonder if other HITs also get this wrong?

I agree that something odd is happening with in_class and other nearby results. I think they should use the same three universes at Quotient. Maybe the easiest fix is to have a Local Definition Q := Quotient@{i j u} R. (or something like that) in the Section?

BTW, I don't think we need a test file for this. I prefer to annotate the definitions themselves when possible, since it provides both documentation and a test.

@jdchristensen
Copy link
Collaborator

Should we close this without merging?

@Alizter Alizter closed this Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants