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

Define matrices as functions #1982

Open
Alizter opened this issue Jun 2, 2024 · 2 comments
Open

Define matrices as functions #1982

Alizter opened this issue Jun 2, 2024 · 2 comments

Comments

@Alizter
Copy link
Collaborator

Alizter commented Jun 2, 2024

In #1979 it was mentioned that matrices might be better defined as functions from a finite domain. This would allow us to remove a lot of boiler plate in the matrix proofs. It should also be possible to characterize path types of matrices without funext since it should be provable for functions with finite domains.

In practice, this means we should redefine vectors as functions from a finite domain since matrices are defined in terms of vectors.

@Alizter
Copy link
Collaborator Author

Alizter commented Jun 3, 2024

@jdchristensen After thinking about this for a bit I actually don't think I know how to prove function extensionality for a finite domain. Even for the empty type, I don't know how to show two functions from the empty type are equal without assuming funext.

It would seem then if we wanted matrices to compute like this, then we will have to introduce funext everytime we prove something with an equality.

@jdchristensen
Copy link
Collaborator

It might still work out well, replacing = by == for statements about vectors and matrices. But it would be pretty radical, so I'm not sure if we want to go there. But so many operations on vectors are naturally expressed componentwise, and would then compute definitionally. map would just become postcomposition, and iterated map would definitionally commute with composition of functions. I guess a summary is that some = would have to be replaced by == (or use funext), while many others would be replaced by definitional equality.

I checked how the Coq standard library does it, and it uses the inductive family approach to defining vectors, which still has the property that nth doesn't definitionally commute with map.

The current approach isn't that bad, just requiring frequent use of rewrite entry_Build_Vector.

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

No branches or pull requests

2 participants