Re: [isabelle] Method sos fails depending on variable names
- To: Dominique Unruh <unruh at ut.ee>
- Subject: Re: [isabelle] Method sos fails depending on variable names
- From: Makarius <makarius at sketis.net>
- Date: Thu, 1 Feb 2018 12:18:33 +0100
- Cc: isabelle-users <isabelle-users at cl.cam.ac.uk>
- In-reply-to: <CAPFfTE4uoEL=xd2u8YEsHo47PivkMBwHX9c1k85oXOWctVwpgg@mail.gmail.com>
- References: <CAPFfTE4a3wPzaM71YMVU5E7wK=HQzsmSrQ=4TjENAc_TWM_0Vg@mail.gmail.com> <0B0D3D89-8C30-46AE-86D4-26814825549A@cam.ac.uk> <CAPFfTE7HxW9KzXHdW00OLH5DVEU+mTUo0+Xz6wCavFJkA6mekg@mail.gmail.com> <E27D0E09-3ECF-4F4B-9455-9944FB100DD2@cam.ac.uk> <CAPFfTE6+iLpE-B9AXp6EEhoKvp5DJJMtThgBnXyn2RL0715OJw@mail.gmail.com> <firstname.lastname@example.org> <CAPFfTE4uoEL=xd2u8YEsHo47PivkMBwHX9c1k85oXOWctVwpgg@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
On 01/02/18 00:32, Dominique Unruh wrote:
> As supposed, there is a mismatch in term orderings, one sorting
> first by string length, the other lexicographically.
> Looking at term_ord.ML, the first would be fast_term_ord, and the
> second term_ord.
> Of course, without understanding the code, we cannot be sure that
> this is exactly what's needed. In particular, there are also calls
> to FuncUtil.cterm_ord (which internally uses fast_term_ord). Should
> they be replaced, too? It does not seem to make a difference for my
> test case, but who knows. In any case, I think replacing
> fast_term_ord in the two places is better than the status quo.
The Isabelle/ML library provides various ways to order terms, and some
other more basic data types like string and indexname.
Working with the Simplifier (or related conversions) usually requires an
ordering that conforms to its policies, notably Term_Ord.term_ord /
termless (sometimes Term_Ord.term_lpo).
Working with auxiliary set/map data structures that need to be fast is
usually done with fast_string_ord, fast_indexname_ord, fast_term_ord
etc. There is no semantic intention behind these orderings, and they can
actually look strange when used for printing a table: the output needs
to be sorted by a more natural order.
With this in mind an educated guess says: FuncUtil tables are right in
using fast_term_ord derivatives and sum_of_squares.ML was wrong using
fast_term_ord with Semiring_Normalizer. This is further supported by the
empiric exploration of Isabelle + AFP: the change c46910a6bfce was
sufficient to make the counter examples work and did not break existing
There is additional confusion in this code base due to preference of
cterm over term: it might be a consequence of porting tools from
HOL-Light, which only has cterm (and calls it term). There are also a
bit too many clones of operations, with non-canonical name and signature
(like simple_cterm_ord, which corresponds to Term_Ord.termless).
This archive was generated by a fusion of
Pipermail (Mailman edition) and