Re: [isabelle] Datatype definition can be slow



Hi Dmitriy,                                                                      
                                                                                 
Thank you for your suggestion.  I can't give a specific example at the moment,   
but generally I need to faithfully translate mutually recursive (typically no    
more than 4) datatype definitions from a variant of ML into HOL, so I can prove  
properties of source programs involving these types using standard proof         
techniques like induction.  The ultimate goal is to verify that the source
program conforms to some formal specification expressed in HOL.                                                     
                                                                                 
A quick test showed that without plugins the definition command finished in a    
few seconds for some of the larger datatypes in my source program.  Not very     
fast, but acceptable.                                                            



> -----Original Messages-----
> From: "Dmitriy Traytel" <traytel at di.ku.dk>
> Sent Time: 2021-04-13 19:43:53 (Tuesday)
> To: "He, Shuhan" <13061136 at buaa.edu.cn>
> Cc: "isabelle-users at cl.cam.ac.uk" <isabelle-users at cl.cam.ac.uk>
> Subject: Re: [isabelle] Datatype definition can be slow
> 
> Hi Shuhan,
> 
> There are a couple of knobs one can turn. For example, a definition like
> 
> datatype t =
>   A00 | A01 | A02 | A03 | A04 | A05 | A06 | A07 | A08 | A09 |
>   A10 | A11 | A12 | A13 | A14 | A15 | A16 | A17 | A18 | A19 |
>   A20 | A21 | A22 | A23 | A24 | A25 | A26 | A27 | A28 | A29 |
>   A30 | A31 | A32 | A33 | A34 | A35 | A36 | A37 | A38 | A39 |
>   A40 | A41 | A42 | A43 | A44 | A45 | A46 | A47 | A48 | A49
> 
> takes something like 30 seconds on my machine. In contrast,
> 
> datatype (plugins only: ) t =
>   A00 | A01 | A02 | A03 | A04 | A05 | A06 | A07 | A08 | A09 |
>   A10 | A11 | A12 | A13 | A14 | A15 | A16 | A17 | A18 | A19 |
>   A20 | A21 | A22 | A23 | A24 | A25 | A26 | A27 | A28 | A29 |
>   A30 | A31 | A32 | A33 | A34 | A35 | A36 | A37 | A38 | A39 |
>   A40 | A41 | A42 | A43 | A44 | A45 | A46 | A47 | A48 | A49
> 
> takes only something like 3 seconds. So the actual datatype constructions (including the simplification theorems which are indeed quadratic in the number
> of constructors) is reasonably fast. The plugins (e.g., size function, code generation setup, transfer theorems, etc.) that were disabled in the second definition provide many useful things too, but have their cost for large datatypes. It depends on the actual application which plugins are actually needed.
> 
> It would help to see your specific example and your requirements (what do you want to do with the type?) to provide further hints.
> 
> Dmitriy
> 
> > On 12 Apr 2021, at 16:39, He, Shuhan <13061136 at buaa.edu.cn> wrote:
> > 
> > Hello fellow researchers,
> > 
> > I'm working on a translator from an ML-like language to HOL, and I'm having a
> > difficulty with translation of inductive datatype definitions.
> > 
> > Datatype definition in Isabelle can be quite slow (at least compared to HOL4)
> > when the number of constructors goes up (say a few dozen), and time consumption
> > seems to be super-linear in the number of constructors.  This has a significant
> > impact on usability since some programs in the source language have very large
> > datatypes, and it's not always feasible to modify the source programs to make
> > them friendlier to Isabelle.  Is the poor performance caused by inherent
> > limitation of the theoretical foundation of the datatype definition package, or
> > suboptimality of implementation of the package?  Also, does the package provide
> > a "quick mode" that skips the slow part of the definition process, while
> > retaining the essential theorems about the datatype being defined?
> > 
> > I once tried to poke into the implementation of the 'datatype' command to find
> > out what's slowing the thing down, but finally got lost in its sheer
> > complexity.  The only potential culprit I found is the simplification theorems,
> > the number of which is quadratic in the number of constructors.
> > 
> > It would be nice to have a datatype definition package without the
> > aforementioned drawback, but given the size and complexity of current
> > implementation, improving it seems extremely difficult.
> > 
> > Your thoughts are greatly appreciated.


This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.