[Agda] original Nat
Sergei Meshveliani
mechvel at botik.ru
Wed Dec 20 12:04:28 CET 2017
On Wed, 2017-12-20 at 09:08 +0100, Ulf Norell wrote:
> Natural number operations _are_ implemented in Agda, and you'll find
> the definitions in
> Agda.Builtin.Nat. The way that they are built in is that when called
> on closed terms (for
> instance 101 + 52), the type checker evaluates that using Haskell
> integer arithmetic rather
> than the Agda definitions.
>
>
> You can read more
> here: http://agda.readthedocs.io/en/latest/language/built-ins.html#natural-numbers
>
>
> Agda.Builtin.Nat is shipped with Agda. You can find its location
> either by middle-clicking
> the module name in Emacs, or by calling Agda from the command line
> with `-v2`:
>
>
> Bla.agda:
> import Agda.Builtin.Nat
> $ agda -v2 Bla.agda
> [..]
Thank you.
Now, I find it on my machine on
/home/mechvel/.cabal/share/x86_64-linux-ghc-7.10.2/Agda-2.5.3/lib/prim/Agda/Builtin/Nat.agda
The problem is as follows.
I have prepared a new certified arithmetic for Bin, including
* _<_ and <-cmp comparison based on lexicographic ordering on bit lists,
* _∸_, divMod, gcd,
* proofs for all important things, like CommutativeMonoid for _+_ and
_*_, and other properties.
The aim is to avoid any built-in arithmetic, with keeping a reasonable
cost order. For example, (divMod x y) needs to cost somewhat O(l^2)
for l = max (bitLength x) (bitLength y).
But:
in some paces it uses the counter cnt : ℕ for termination proof
(I do not know how to arrange some termination proofs without using
toℕ).
It is initially obtained by (Bin.toℕ b), and works in the loops by
pattern-matching against (1+ cnt).
Now, I need a performance test showing that, for example, divMod x y
has the intended cost order.
And it does so.
But:
(Bin.toℕ b) applies Nat._+_ and (Nat._*_ 2) in a loop at the
running time.
The cost order for operating with cnt can be small due to the two
reasons:
(1) lazy evaluation of toℕ, with stepping from (1+ cnt) to cnt
a few number of times,
(2) built-in performance for Nat._+_ and (Nat._*_ 2).
I need to make sure that the source of (2) can be removed.
For this, I, probably, need to switch out built-ins for all Nat items,
with letting them evaluate really in _unary_ system. For example,
(Nat.+ 101 52) to compute in 53 steps of pattern matching.
Right?
How does one arrange this?
Needs one to edit the file
.../share/x86_64-linux-ghc-7.10.2/Agda-2.5.3/lib/prim/Agda/Builtin/Nat.agda
with removing all the lines containing the pragma of
{-# BUILTIN ... #-}
?
Thanks,
------
Sergei
>
> On Tue, Dec 19, 2017 at 7:43 PM, Sergei Meshveliani <mechvel at botik.ru>
> wrote:
> Please, what is a regular way to switch between the built-in
> Nat
> arithmetic and the original one (implemented in Agda) ?
>
> Data.Nat.Base of lib-0.14 contains
>
> open import Agda.Builtin.Nat public using ( zero; suc; _+_;
> _*_ )
> renaming ( Nat to ℕ; _-_
> to _∸_ )
>
> But I do not find the module Agda.Builtin.Nat.
>
> I need to use the Nat arithmetic programmed in Agda
> (ℕ; _+_, _*_, _∸_, _≤_ ...) as in early days.
>
> Thanks,
>
> ------
> Sergei
>
> _______________________________________________
> Agda mailing list
> Agda at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/agda
>
>
More information about the Agda
mailing list