-
Notifications
You must be signed in to change notification settings - Fork 632
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
Fixing part of #5669: unification heuristics sensitive to alphabet #924
Fixing part of #5669: unification heuristics sensitive to alphabet #924
Conversation
This reminds me a lot of universe minimization being sensitive to the file name, for similar reasons. So indeed, there may be other instances of the same problem. |
0771d63
to
29c0896
Compare
You're right. We indeed had similar bugs already. |
Wow, that one's deserve a praise indeed! The fix looks good to me. |
May the fix for some of the cases be performance-sensitive? |
It adds a search through the evar context for each possible solutions when more than one is available, and, in common problems, this number rarely exceeds two (one for the dependent case, one for the non dependent case). Even on the worst artificial examples, it would add at most a O(n^2) cost on the number of variables in the context when several solutions exist, which is a cost common in unification. In theory, we could absorb this cost, by remembering the original position of each variable in the context, but by doing so we would allocate more, always. I'm not the complexity expert around, but I believe that working on compacting the identity part of instances would for instance be worther. Also, worther, even if liable to randomly affect the complexity, shall be various expected improvements of the unification such as not dropping too early exploration paths as we do now. |
…ce of names). This surprising bug was caused by an Id.Set which was ordering solutions to variable-projection problems in ascii order. We fix it by re-considering the variables involved in the solutions using the declaration order. Note that in practice, this implies preferring a dependent solution over a non-dependent one.
29c0896
to
c24bcae
Compare
Just realized that I did not correctly push an optimization (my previous answer was relative to this further simplification). |
I guess a pendulum run should tell us if there's any impact. |
Hum, I feel that this will be without noticeable impact but a test is started here. Edit: result gives minor variations with extrema +1.2 and -0.86. |
I took the initiative to remove the |
Indeed, the complete results are as follow:
and the |
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR coq#924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause.
This refines even further c24bcae (PR #924) and 6304c84: - c24bcae fixed the order in the heuristic - 6304c84 improved the order by preferring projections There remained a dependency in the alphabetic order in selecting unification candidates. The current commit fixes it. We radically change the representation of the substitution to invert by using a map indexed on the rank in the signature rather than on the name of the variable. More could be done to use numbers further, e.g. for representing aliases. Note that this has consequences on the test-suite (in output/Notations.v) as some problems now infer a dependent return clause. (cherry picked from commit 99ffdbb)
A sensitivity to the order in which objects are stored in an OCaml
Set
structure.See bug report #5669 and commit message for details.
May other similar bugs hang around?