Skip to content

Comments

Fast.Int Update#1280

Merged
mortberg merged 16 commits intoagda:masterfrom
LorenzoMolena:fast-int-update-without-order
Feb 20, 2026
Merged

Fast.Int Update#1280
mortberg merged 16 commits intoagda:masterfrom
LorenzoMolena:fast-int-update-without-order

Conversation

@LorenzoMolena
Copy link
Contributor

@LorenzoMolena LorenzoMolena commented Dec 16, 2025

See #1276.
I have decided to change the organization of the modules by introducing a common Fast directory, hosting the fast Int modules and, in the future, fast rationals as well. The same change has been made for instances of algebraic structures.
In my opinion, this organization seems conceptually clearer.
For example, in #1276 the instances of fast integers as AbGroup are in Cubical.Algebra.AbGroup.Instances.Int.Fast, with the file named Fast, whereas in this PR we have Cubical.Algebra.AbGroup.Instances.Fast.Int, with the file named Int.

Moreover, since in these PRs they are consistently referred to as "fast integers", having them under Fast.Int appears more natural than the current Int.Fast.

Finally, the only fast Int module already merged is the Base file, so this reorganization is minimal.

Update

After discussing with @marcinjangrzybowski, we agreed to adopt a different notion of order than the one currently used in the draft of #1276, and to update this PR accordingly, including the order module together with the related order instances.
In particular, I am not using Marcin’s solver for fast integers, since it is not required for this part of the development. There will still be a separate PR for the solver, which will be especially useful for the development of Fast Rationals, where it can help avoid long chains of equational reasoning.

This implementation of the order is inspired by Agda’s standard library and 1Lab, but relies on _<ᵗ_ from Cubical.Data.Nat.Order.Inductive rather than the order from Cubical.Data.Nat.Order (which is defined as a sigma type).

The main advantages are that implicit arguments are easier to infer and that the definitions reduce efficiently on concrete numerals, as can be seen by normalizing the proofs of decidability

I would also appreciate feedback on a few design choices in this PR. In particular, I experimented with the DISPLAY pragma to obtain a more informative printing of comparison results. I found it convenient, but I do not have strong feelings about keeping it, so I am happy to adjust if preferred.

LorenzoMolena and others added 9 commits November 19, 2025 09:52
* add fast implementation of integers and their properties

* move properties of min and max over `ℕ` to the appropriate file

* reorganize and format code

* remove `--safe` flag

* remove `--safe` flag

* Fast int (#2)

* direct solver application

* direct solver application

---------

Co-authored-by: Marcin Jan Turek-Grzybowski <marcinjangrzybowski@gmail.com>

* add fast implementation of integers and their properties

* move properties of min and max over `ℕ` to the appropriate file

* reorganize and format code

* remove `--safe` flag

* remove `--safe` flag

* remove `--safe` flag

* Fast int (#2)

* direct solver application

* direct solver application

---------

Co-authored-by: Marcin Jan Turek-Grzybowski <marcinjangrzybowski@gmail.com>

* fix compatibility with the library

* fix compatibility after rebase, start proving properties of fast integer min and max

* add instances of `Nat` and `Int` as `Pseudolattice`, and of `Int` as `OrderedCommRing`

* fix typo, add better make from Posets to Pseudolattices

* update `makePseudolatticeFromPoset` and instances built using it

* move `maxLUB` and `minGLB` to `Data.Nat.Order`, remove unnecessary imports

* rewrite properties from `minAssoc` to `-max`, add temporary lemmas in `Nat`, add `UsingEq` into `min` and `max` over the Naturals

* fix naming clash on import

* rewrite properties from `pos+posLposMin` to `·DistNegsucLMax`

* start work on Order: adapt properties from `isProp≤` to `≤SumLeftPos`, add boolean order, suggest alternative definition `_≤'_`

* use more efficient implementation of quotient and remainder in `Int.Fast.Divisibility`

* adapt properties from `pred-≤-pred` to `0≤o→≤-·o`, move import of `Bool.Base` together with the other imports

* adapt properties from `<-·o` to `predℤ-≤-predℤ`

* adapt properties from `¬m+posk<m` to `<-+pos-trans`

* adapt properties from `<-pos+-trans` to `0<o→≤-·o-cancel`

* adapt properties from `≤-o·-cancel` to `≤→min` ; add conversions between the order over the integers and the one over the naturals ; add `maxLUB`, `minGLB` , `≤→max` , `≤→min` to `Data.Nat.Order`

* adapt properties from `≤MonotoneMin` to `_≟'_` ; add faster `_≟_` and tests. This finishes (a first but complete version) of `Data.Int.Fast`

* edit `_≤'_` using recursive order, add `_≤ᵇ_` and `_≤''_`

* update `minIdem`

* clean comments, reorganize `Fast` modules, add more properties in `Int.Fast.Order`, add `Trichotomy` and `Ordering` in `BinaryRelation`

* add fixity for `_≤_` in `PseudolatticeStr`, add `Properties` file

* edit Fast using PL and OCR instances

* remove `minIdem`, use PL instance of `Nat` in the `Int.Fast.Order` module

* simplify some proofs, with additional converions between the order on Nat and the integer order between negsuc

* Add order related instances of `Fast.Int`

* revert addition of `Trichotomy` to `BinaryRelation`, add more tests to `Int.Fast.Order`

* add missing `'` on commented test code

* adapt instances of `Int` and `Int.Fast` as `OCR`, to the branch `ocr+pl-instances'`

---------

Co-authored-by: Ettore Forigo <ettore.forigo@gmail.com>
Co-authored-by: Marcin Jan Turek-Grzybowski <marcinjangrzybowski@gmail.com>
…seudolattices and simplify some proofs about min/max in `Int.Fast.Properties`
@anshwad10
Copy link
Contributor

"Fast" doesn't feel like a word to me anymore, after reading that 😄

LorenzoMolena and others added 6 commits January 24, 2026 14:33
* Resolve naming inconsistency between Iso and Category.isIso (agda#1274)

s/leftInv/ret; s/rightInv/sec

---------

Co-authored-by: Madeleine Sydney Ślaga <msyds@deertopia.net>

* isIso name change fix (agda#1281)

* Update fin (agda#1279)

* Exchange Fin in Cubical.Data.Fin for the deifinition from Cubical.Data.Fin.Inductive. WIP

* Fixed finj, predFin, inject<, flast, ¬Fin0 to work with new definition of Fin.

* Minor changes

* Fix sumFinGen

* fix any?

* Everything type checks now. Important changes:
- Implicit argument added to toN
- Implicit arguments in toN-injective slightly changed
- Argument changed from implicit to explicit in elim

* some formatting

* change ¬Fin0

* remove comments

* Add <ᵗ-asym

* make properties type check

* Remove dependencies on Cubical.Data.Fin.Inductive.Base

* Things that work

* Properties type check

* more working files

* factorEquiv

* comment fix

* LehmerCode type checks

* SumFin.Base type checks

* some cleanup and Axiom.Choice type checks not reliant on old Fin

* Remove dependence on Fin.Inductive

* Remove dependence on Fin.Inductive

* Remove dependency on Fin.Infuctive

* Remove dependency on Fin.Inductive

* Remove dependencies on Fin.Inductive

* type check

* fix FinSet

* _<ᵗ_ is well founded

* type checks with new Fin

* Everything builds

* Move everything from Fin.Inductive.Properties to Fin.Properties and remove Fin.Inductive, Fin.Inductive.Base, Fin.Inductive.Properties

* some cleanup

* more cleanup

* fix trailing whitespaces

* files end with newline

---------

Co-authored-by: croos <76143n@gmail.com>

* fix defintions of `min` and `max`, add comment on limitations of `UsingEq` (agda#1270)

* Change implementation of Inductive Order on Nat (agda#1283)

* use boolean comparison in `Nat.Order.Inductive`, add non-strict and flipped inductive order, make faster instance search in `Fin.Literals`

* fix typo

* Place holder for paper (agda#1286)

* placeholder

* whitespae

* Cellpaper2 (agda#1287)

* placeholder

* whitespae

* form

* fix imports: `Fin.Inductive.Base/Properties` → `Fin.Base/Properties`

---------

Co-authored-by: Madeleine Sydney Ślaga <65362461+msyds@users.noreply.github.com>
Co-authored-by: Madeleine Sydney Ślaga <msyds@deertopia.net>
Co-authored-by: Max S. New <maxsnew@gmail.com>
Co-authored-by: Caroline Roos <croos.math@gmail.com>
Co-authored-by: croos <76143n@gmail.com>
Co-authored-by: Axel Ljungström <49276137+aljungstrom@users.noreply.github.com>
Copy link
Collaborator

@mortberg mortberg left a comment

Choose a reason for hiding this comment

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

Only a question, otherwise everything looks good. Is it ready to be merged?

¬>ℕ→¬negsuc<negsuc : ∀ {x y} → ¬ (x ℕ.>ᵗ y) → ¬ negsuc x < negsuc y
¬>ℕ→¬negsuc<negsuc ¬p (negsuc<negsuc p) = ¬p p

{-# DISPLAY negsuc≤negsuc {x} {y} _ = negsuc x ≤ negsuc y #-}
Copy link
Collaborator

@mortberg mortberg Feb 19, 2026

Choose a reason for hiding this comment

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

What do these DISPLAY pragmas do?

Copy link
Contributor Author

@LorenzoMolena LorenzoMolena Feb 19, 2026

Choose a reason for hiding this comment

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

They are used to show more informative outputs when running the properties.
I found it useful while writing the code, in particular for the proofs of decidability of order and of trichotomy:

  • running 123456 <? 123455 shows no (¬ pos 123456 < pos 123455) instead of no (¬<ℕ→¬pos<pos (λ x → x))
  • running -123455 ≟ -123456 shows gt (negsuc 123455 < negsuc 123454) instead of gt (negsuc<negsuc tt)

Copy link
Collaborator

Choose a reason for hiding this comment

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

@flgrubm I wonder if this trick could be used to make category theory goals more readable as well

@LorenzoMolena
Copy link
Contributor Author

Only a question, otherwise everything looks good. Is it ready to be merged?

Yes, it is ready to be merged

@mortberg mortberg merged commit 762f7a2 into agda:master Feb 20, 2026
1 check passed
@mortberg
Copy link
Collaborator

Only a question, otherwise everything looks good. Is it ready to be merged?

Yes, it is ready to be merged

Thanks a lot for the contribution!

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