Skip to content

Conversation

@LorenzoMolena
Copy link
Contributor

While working on a future PR, I noticed that when performing a "with-abstraction with UsingEq" on n <ᵇ m, each case was not normalizing to the expected term.
This issue is resolved by adding UsingEq into the definitions of min and max. Interestingly, all proofs that relied on "with-abstraction withot UsingEq" still works unchanged.

I added a comment about this limitation above the definition of UsingEq, but I'm not entirely sure how clear it is, so I also referenced its use in min and max over ℕ.
Please let me know if there is a clearer way to explain this behavior.

@mortberg
Copy link
Contributor

Why not just define min and max by recursion without any with or calls to <?

@mortberg
Copy link
Contributor

So having min (suc n) (suc m) = min n m and similarly for max

@anshwad10
Copy link
Contributor

Why not just define min and max by recursion without any with or calls to <?

They made it like this in #1262 for efficiency, because the _<ᵇ_ builtin is faster than recursing

@anshwad10
Copy link
Contributor

Also, I think this is precisely the advantage of using inspect over UsingEq, because when using inspect we abstract on the value of n <ᵇ m and the path separately

@mortberg
Copy link
Contributor

Ah right, I had forgotten about that. I wonder how much one should worry about efficiency for functions on unary nat though... If we want things to be fast we should at least have a binary representation?

@anshwad10
Copy link
Contributor

Ah right, I had forgotten about that. I wonder how much one should worry about efficiency for functions on unary nat though... If we want things to be fast we should at least have a binary representation?

I don't know if that would help; It wouldn't be better in terms of storage at least, because Agda compiles Nat to built in arbitrary-precision binary integers, and idt it would speed up arithmetic because the builtin operations are O(1) while binary arithmetic is O(logN)

@marcinjangrzybowski
Copy link
Contributor

@mortberg this is part of work to enable fast operations on Integers -> Rationals -> and finaly beeing able to quickly calculatate things like Nth digit of e in #1182 :)
@LorenzoMolena identified bootlenecks, and we have very promising experiments.
We discussed those plans with @felixwellen , but are happy to meet @mortberg to get the feedback on our plan.
With @LorenzoMolena , we will be doing code sprint hopefully integrating this work, 2 weeks from now during AIM.

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.

4 participants