From joe at gilith.com Thu Apr 5 04:07:48 2012
From: joe at gilith.com (Joe Hurd)
Date: Wed, 4 Apr 2012 21:07:48 -0700
Subject: [opentheory-users] a standalone tactic translating numeral
encodings
In-Reply-To:
References:
Message-ID:
Hi Ramana,
This is extremely impressive work - nice job!
By the way, I tried calling it from HOL Light but couldn't make it
work - does it use your standard convention that the conversion
accepts an axiom of the form `K F n[N]` and returns a theorem of the
form `|- n[N] = n[B]`? My attempt is at the bottom of the file
opentheory/cloud.ml in my HOL Light fork.
> Specific design questions I have:
> ?- would it be better to somehow write articles without going via a type of
> proofs (i.e. just directly log as theorems are built)? I tried to figure out
> a way to do that but failed, and also stopped thinking it would be better
I like the way you have it right now with a datatype of proofs.
> ?- would it be more efficient to store conclusions with proofs rather than
> computing them with concl? but I think Haskell memoises anyway...
My gut reaction is that this would be a false economy. It's much
clearer the way you have it now.
> ?- is there a better algorithm for converting between these numeral
> encodings?
From joe at gilith.com Thu Apr 5 04:19:35 2012
From: joe at gilith.com (Joe Hurd)
Date: Wed, 4 Apr 2012 21:19:35 -0700
Subject: [opentheory-users] WFREC
In-Reply-To: <4F2B332A.9060709@nicta.com.au>
References:
<4F2B332A.9060709@nicta.com.au>
Message-ID:
[While I'm finally catching up on my email] one thing I might add to
this discussion is that constants and type operators that are specific
to the infrastructure of a single theorem prover don't necessarily
have to be part of the OpenTheory standard theory library. The
constants you list don't appear in the final theorems returned by the
recursive function definition package, but are simply used to prove
that the desired recursive functions exist. The relevant theory
infrastructure could be "statically linked" in theories exported from
HOL4.
However, I'm not saying that such constants should never appear in
OpenTheory. It may well be the case that, say, RESTRICT is a perfectly
general operator for restricting the domain of relations that could be
useful in a variety of contexts, and if that was the case then it
would be a good addition to the Relation namespace.
Cheers,
Joe
On Thu, Feb 2, 2012 at 5:06 PM, Michael Norrish
wrote:
> On 26/01/12 00:42, Ramana Kumar wrote:
>> I'm thinking about the appropriate namespace for a recursion operator for wellfounded relations.
>> In HOL4 it is called WFREC and is in relationTheory.
>> In fact there is a small suite of related definitions there: RESTRICT, approx, and the_fun.
>> I'm wondering if the list has any ideas about an appropriate way to package these things up (i.e. under what name, or with what other stuff).
>> I realize I may need to give more background about what they actually do... (don't have that on me at the moment!)
>
> These are operators used to define functions that recurse in well-founded ways. ?I can see that they are not necessarily automatic fits for the relation theory, though they're obviously pretty tightly dependent on the WF notion from relation theory.
>
> How about a new theory called something like recursive functions? ?(Of course, the problem with this is the possible confusion with the computable functions...) ?Failing that, just put them into relation!
>
> Michael
>
>
>
> _______________________________________________
> opentheory-users mailing list
> opentheory-users at gilith.com
> http://www.gilith.com/mailman/listinfo/opentheory-users
>
From konrad.slind at gmail.com Thu Apr 5 04:37:40 2012
From: konrad.slind at gmail.com (Konrad Slind)
Date: Wed, 4 Apr 2012 23:37:40 -0500
Subject: [opentheory-users] WFREC
In-Reply-To:
References:
<4F2B332A.9060709@nicta.com.au>
Message-ID:
Yes, probably WFREC doesn't need to be there, just the final theorems.
Note that relationTheory is quite simple, in that it is just based on
'a -> 'a -> bool
That means that there are lots of "wellfoundedness" operators
that probably shouldn't get transported to relationTheory. I'm thinking
of "measure" in particular, which has type
('a -> num) -> 'a -> 'a -> bool
and belongs in whatever basic theory of natural numbers you've got.
Konrad.
On Wed, Apr 4, 2012 at 11:19 PM, Joe Hurd wrote:
> [While I'm finally catching up on my email] one thing I might add to
> this discussion is that constants and type operators that are specific
> to the infrastructure of a single theorem prover don't necessarily
> have to be part of the OpenTheory standard theory library. The
> constants you list don't appear in the final theorems returned by the
> recursive function definition package, but are simply used to prove
> that the desired recursive functions exist. The relevant theory
> infrastructure could be "statically linked" in theories exported from
> HOL4.
>
> However, I'm not saying that such constants should never appear in
> OpenTheory. It may well be the case that, say, RESTRICT is a perfectly
> general operator for restricting the domain of relations that could be
> useful in a variety of contexts, and if that was the case then it
> would be a good addition to the Relation namespace.
>
> Cheers,
>
> Joe
>
> On Thu, Feb 2, 2012 at 5:06 PM, Michael Norrish
> wrote:
>> On 26/01/12 00:42, Ramana Kumar wrote:
>>> I'm thinking about the appropriate namespace for a recursion operator for wellfounded relations.
>>> In HOL4 it is called WFREC and is in relationTheory.
>>> In fact there is a small suite of related definitions there: RESTRICT, approx, and the_fun.
>>> I'm wondering if the list has any ideas about an appropriate way to package these things up (i.e. under what name, or with what other stuff).
>>> I realize I may need to give more background about what they actually do... (don't have that on me at the moment!)
>>
>> These are operators used to define functions that recurse in well-founded ways. ?I can see that they are not necessarily automatic fits for the relation theory, though they're obviously pretty tightly dependent on the WF notion from relation theory.
>>
>> How about a new theory called something like recursive functions? ?(Of course, the problem with this is the possible confusion with the computable functions...) ?Failing that, just put them into relation!
>>
>> Michael
>>
>>
>>
>> _______________________________________________
>> opentheory-users mailing list
>> opentheory-users at gilith.com
>> http://www.gilith.com/mailman/listinfo/opentheory-users
>>
>
> _______________________________________________
> opentheory-users mailing list
> opentheory-users at gilith.com
> http://www.gilith.com/mailman/listinfo/opentheory-users
From ramana.kumar at gmail.com Thu Apr 5 05:26:10 2012
From: ramana.kumar at gmail.com (Ramana Kumar)
Date: Thu, 5 Apr 2012 06:26:10 +0100
Subject: [opentheory-users] a standalone tactic translating numeral
encodings
In-Reply-To:
References:
Message-ID:
On Thu, Apr 5, 2012 at 5:07 AM, Joe Hurd wrote:
> Hi Ramana,
>
> This is extremely impressive work - nice job!
>
> By the way, I tried calling it from HOL Light but couldn't make it
> work - does it use your standard convention that the conversion
> accepts an axiom of the form `K F n[N]` and returns a theorem of the
> form `|- n[N] = n[B]`? My attempt is at the bottom of the file
> opentheory/cloud.ml in my HOL Light fork.
>
Yes I believe it is using that convention.
My guess is that you're generating an article with HOLLight.BIT2 rather
than Number.Natural.bit2, but I haven't actually run your attempt.
If that's not the problem it would be helpful if you could send me the
article that gets passed to the web tactic (or maybe I should have some
infrastructure for saving it...)
>
> > Specific design questions I have:
> > - would it be better to somehow write articles without going via a type
> of
> > proofs (i.e. just directly log as theorems are built)? I tried to figure
> out
> > a way to do that but failed, and also stopped thinking it would be better
>
> I like the way you have it right now with a datatype of proofs.
>
> > - would it be more efficient to store conclusions with proofs rather
> than
> > computing them with concl? but I think Haskell memoises anyway...
>
> My gut reaction is that this would be a false economy. It's much
> clearer the way you have it now.
>
I guess if the performance is bad then profiling or benchmarks will decide
this (and for now there's no real need to obscure the code..)
>
> > - is there a better algorithm for converting between these numeral
> > encodings?
>
> From reading your code it's not entirely clear what your algorithm is.
> Could you briefly explain it?
>
The function n2b near the top of the file is the algorithm.
It's been a while, so let's see if I can figure out the algorithm just by
reading that code...
Recursive descent on the structure of Norrish numerals.
Easy cases:
n2b 0 = 0,
n2b (bit1 n) = bit1 (n2b n).
Difficult case:
n2b (bit2 n) =
we use a theorem |- bit2 n = suc (bit1 n)
then use the function binc to turn the suc into binary.
binc just does the obvious recursion using the following theorems:
|- suc 0 = bit1 0
|- suc (bit0 n) = bit1 n
|- suc (bit1 n) = bit0 (suc n)
>
> > - my articles always leave tonnes of stuff on the stack because they
> just
> > def everything... is there an efficient algorithm for only deffing things
> > you'll actually use (and maybe removing them after you won't any more)?
>
> I don't think it's worth being super clean for "temporary articles"
> used in cloud tactics. The opentheory tool does a clean up of "archive
> articles" as part of installing theories to your local opentheory
> directory.
>
fair enough
>
> > - probably lots of obvious things I'm doing less nicely than is
> possible...
>
> There are many people in the world who are more of a Haskell expert
> than me, but one thing that jumps out at me is that most of your
> top-level declarations don't have type declarations, which are good
> compiler-checked documentation.
>
true... I was busy being impressed by type inference...
>
> Cheers,
>
> Joe
>
> _______________________________________________
> opentheory-users mailing list
> opentheory-users at gilith.com
> http://www.gilith.com/mailman/listinfo/opentheory-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From joe at gilith.com Thu Apr 5 22:10:16 2012
From: joe at gilith.com (Joe Hurd)
Date: Thu, 5 Apr 2012 15:10:16 -0700
Subject: [opentheory-users] a standalone tactic translating numeral
encodings
In-Reply-To:
References:
Message-ID:
Hi Ramana,
> My guess is that you're generating an article with HOLLight.BIT2 rather than
> Number.Natural.bit2, but I haven't actually run your attempt.
> If that's not the problem it would be helpful if you could send me the
> article that gets passed to the web tactic (or maybe I should have some
> infrastructure for saving it...)
I've attached the article encoding the goal: FYI the opentheory
summary for it is:
$ opentheory info n2b-goal.art
3 input type operators: -> bool Number.Natural.natural
5 input constants: F Function.K Number.Natural.bit1 Number.Natural.bit2
Number.Natural.zero
1 assumption:
|- Function.K F
(Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
1 theorem:
|- Function.K F
(Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
> The function n2b near the top of the file is the algorithm.
> It's been a while, so let's see if I can figure out the algorithm just by
> reading that code...
Your algorithm looks absolutely fine, and should scale up to any size
of natural number that a theorem prover could conceivably process.
Cheers,
Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: n2b-goal.art
Type: application/octet-stream
Size: 899 bytes
Desc: not available
URL:
From joe at gilith.com Thu Apr 5 22:20:51 2012
From: joe at gilith.com (Joe Hurd)
Date: Thu, 5 Apr 2012 15:20:51 -0700
Subject: [opentheory-users] WFREC
In-Reply-To:
References:
<4F2B332A.9060709@nicta.com.au>
Message-ID:
Hi Konrad,
> Note that relationTheory is quite simple, in that it is just based on
>
> ? 'a -> 'a -> bool
>
> That means that there are lots of "wellfoundedness" operators
> that probably shouldn't get transported to relationTheory. I'm thinking
> of "measure" in particular, which has type
>
> ? ('a -> num) -> 'a -> 'a -> bool
>
> and belongs in whatever basic theory of natural numbers you've got.
This intertwining of basic theories is just the kind of thing that
OpenTheory was designed to handle. Right now the standard relation
theory
http://opentheory.gilith.com/?pkg=relation
includes subtheories that just depend on basic stuff, and a
relation-natural subtheory that depends on the theory of natural
numbers and defines a 'measure' constant with the type you give.
Cheers,
Joe
From ramana.kumar at gmail.com Fri Apr 6 06:25:48 2012
From: ramana.kumar at gmail.com (Ramana Kumar)
Date: Fri, 6 Apr 2012 07:25:48 +0100
Subject: [opentheory-users] a standalone tactic translating numeral
encodings
In-Reply-To:
References:
Message-ID:
My code works fine on this article. The problem was my CGI script. It
should be fixed now.
(It had a call to runhaskell n2b.hs which got confused when called from
another directory, so now I've given it an absolute path to n2b.hs.)
On Thu, Apr 5, 2012 at 11:10 PM, Joe Hurd wrote:
> Hi Ramana,
>
> > My guess is that you're generating an article with HOLLight.BIT2 rather
> than
> > Number.Natural.bit2, but I haven't actually run your attempt.
> > If that's not the problem it would be helpful if you could send me the
> > article that gets passed to the web tactic (or maybe I should have some
> > infrastructure for saving it...)
>
> I've attached the article encoding the goal: FYI the opentheory
> summary for it is:
>
> $ opentheory info n2b-goal.art
> 3 input type operators: -> bool Number.Natural.natural
> 5 input constants: F Function.K Number.Natural.bit1 Number.Natural.bit2
> Number.Natural.zero
> 1 assumption:
> |- Function.K F
> (Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
> 1 theorem:
> |- Function.K F
> (Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
>
> > The function n2b near the top of the file is the algorithm.
> > It's been a while, so let's see if I can figure out the algorithm just by
> > reading that code...
>
> Your algorithm looks absolutely fine, and should scale up to any size
> of natural number that a theorem prover could conceivably process.
>
> Cheers,
>
> Joe
>
> _______________________________________________
> opentheory-users mailing list
> opentheory-users at gilith.com
> http://www.gilith.com/mailman/listinfo/opentheory-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From joe at gilith.com Fri Apr 6 20:31:53 2012
From: joe at gilith.com (Joe Hurd)
Date: Fri, 6 Apr 2012 13:31:53 -0700
Subject: [opentheory-users] a standalone tactic translating numeral
encodings
In-Reply-To:
References:
Message-ID:
Yep, looks like it works fine now, in case we ever need to de-Norrish
some numerals from HOL Light.
Cheers,
Joe
On Thu, Apr 5, 2012 at 11:25 PM, Ramana Kumar wrote:
> My code works fine on this article. The problem was my CGI script. It should
> be fixed now.
> (It had a call to runhaskell n2b.hs which got confused when called from
> another directory, so now I've given it an absolute path to n2b.hs.)
>
> On Thu, Apr 5, 2012 at 11:10 PM, Joe Hurd wrote:
>>
>> Hi Ramana,
>>
>> > My guess is that you're generating an article with HOLLight.BIT2 rather
>> > than
>> > Number.Natural.bit2, but I haven't actually run your attempt.
>> > If that's not the problem it would be helpful if you could send me the
>> > article that gets passed to the web tactic (or maybe I should have some
>> > infrastructure for saving it...)
>>
>> I've attached the article encoding the goal: FYI the opentheory
>> summary for it is:
>>
>> $ opentheory info n2b-goal.art
>> 3 input type operators: -> bool Number.Natural.natural
>> 5 input constants: F Function.K Number.Natural.bit1 Number.Natural.bit2
>> ?Number.Natural.zero
>> 1 assumption:
>> ?|- Function.K F
>> ? ? ? (Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
>> 1 theorem:
>> ?|- Function.K F
>> ? ? ? (Number.Natural.bit2 (Number.Natural.bit1 (Number.Natural.bit2 0)))
>>
>> > The function n2b near the top of the file is the algorithm.
>> > It's been a while, so let's see if I can figure out the algorithm just
>> > by
>> > reading that code...
>>
>> Your algorithm looks absolutely fine, and should scale up to any size
>> of natural number that a theorem prover could conceivably process.
>>
>> Cheers,
>>
>> Joe
>>
>> _______________________________________________
>> opentheory-users mailing list
>> opentheory-users at gilith.com
>> http://www.gilith.com/mailman/listinfo/opentheory-users
>>
>
>
> _______________________________________________
> opentheory-users mailing list
> opentheory-users at gilith.com
> http://www.gilith.com/mailman/listinfo/opentheory-users
>