*To*: Manuel Eberl <eberlm at in.tum.de>, Dominique Unruh <unruh at ut.ee>*Subject*: Re: [isabelle] Datatype definition can be slow*From*: Dmitriy Traytel <traytel at di.ku.dk>*Date*: Tue, 13 Apr 2021 23:02:00 +0000*Accept-language*: en-US, da-DK*Arc-authentication-results*: i=1; mx.microsoft.com 1; spf=pass (sender ip is 192.38.125.140) smtp.rcpttodomain=in.tum.de smtp.mailfrom=di.ku.dk; dmarc=pass (p=none sp=none pct=100) action=none header.from=di.ku.dk; dkim=none (message not signed); arc=none*Arc-message-signature*: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hY9Lw8jH8UN/M+M2n7BRtmqTgC5Ucey4OJiKMgCWRWg=; b=KDbY0C33INJhPXCFk87a2IuSmr3aOJySuP7rqNNFbKgDnQhh6JFM1CDfPYnm6T3XQTyjh9U9OEM2RuPWWZW2LMt+eoIQanekUL6JOiqigBRdqduAPIUenLT/axZ9i8j/S63lDcm6fhEVHNNvv7Het5MfDNP3a5UoNSL8fXSWza/jordxD1QST/MZVJ98XBaGP7bl8j4a386Ikuk/mL38Gg9qW4P7de3FEASyC4oiI/Tl8LebvZ7Sh4bH/SBkM+zqhoD/hdVhTiPw1v1t9+H5mY8rhw44kijUNBdhNLxIoH9cRoPPsbHPZIcAMJV5Az+SzKqeCGpDlZTr6uhu+egVNw==*Arc-seal*: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AkLyKHbau06sxgSpaGuRUWzgL+VTeH21ObuSlIHWF3x2L3ZOHbQRDi0O2AA1+EnZWB+PNNQ0EonYXR2tShNSO783JG9g+fcVY727KYw4Ev/vpjpxn25pyx9QkcHg6bczIblGkd+dT6tzBk4Q3Qnx0+nWAHMXHOtjXqlNbLdnZYvPrcsULtwqqMH5mjxGBGRa8X/AkeBPKKa7pLoQKs+uZOFaSLue6WutAh1YZq1US5o4Nqx2+o55gqA2M/+MWPSyrKlUoZH6egfqmaFX74rz5Q/cCBWqYw7Z0ZJhspL7WtZkhFGfGrgK9yWHXWp1W06WODWQ6jwWye1ucuU/TmtJMA==*Cc*: "cl-isabelle-users at lists.cam.ac.uk" <cl-isabelle-users at lists.cam.ac.uk>*In-reply-to*: <77d2e2ee-cfda-fbc7-3bdc-f6189bfff00a@in.tum.de>*References*: <a0701ab.2b705.178c68638b8.Coremail.13061136@buaa.edu.cn> <9674D5AE-0AB1-476F-85EF-7E2964840F6F@di.ku.dk> <77d2e2ee-cfda-fbc7-3bdc-f6189bfff00a@in.tum.de>*Thread-index*: AQHXME6USuEHxbShiUWe2GMCfoKBq6qyMmqAgAA3HYCAAIZZAA==*Thread-topic*: [isabelle] Datatype definition can be slow

Hi Dominique & Manuel, Using a simproc for proving distinctness for datatypes with a large number of constructors was the behavior for the old datatype package, see e.g., [1, p32]. When developing the new package it was a deliberate decision to get rid of this special case. IIRC the reasoning was that distinctness is just one example of a quadratic fact (quadratically many theorems of constant size). There are others, e.g., the case theorems, which are linearly many each of linear size, so also quadratic altogether. So if one decides to seriously battle the quadratic behavior, one has to develop special cases for every such fact (and the cute constructor’s numbering trick will not always work). Also, a simproc has the big downside of being virtually invisible for Sledgehammer (and other tools that are not simp). Moreover considering my below measurements: before optimizing the 3 second datatype declaration (which proves all 2450 distinctness theorems), I think we should rather understand the 27 seconds that are spend in the plugins (specifically, code, transfer, and quickcheck seem to be the culprits). I would still be interested to see the original problematic example (the number of constructors is only one aspect that affects performance). Dmitriy [1] https://isabelle.in.tum.de/website-Isabelle2012/dist/Isabelle2012/doc/logics-HOL.pdf > On 13 Apr 2021, at 17:01, Manuel Eberl <eberlm at in.tum.de> wrote: > > Somebody once voiced the possibility of making it possible to switch off > the simplification lemmas (e.g. for constructor distinctness, of which > there are quadratically many) and replace them by a simproc that proves > them ad-hoc whenever one of them is needed. > > This would make applying the theorems slightly more expensive, but > eliminate the need to prove all of them beforehand. > > Not sure if this becomes enough of a problem to be worth it or if the > existing construction is fast enough for any reasonably-sized datatype. > > Manuel > > > On 13/04/2021 13:43, Dmitriy Traytel wrote: >> 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. >> >> >

**References**:**[isabelle] Datatype definition can be slow***From:*He, Shuhan

**Re: [isabelle] Datatype definition can be slow***From:*Dmitriy Traytel

**Re: [isabelle] Datatype definition can be slow***From:*Manuel Eberl

- Previous by Date: Re: [isabelle] Datatype definition can be slow
- Next by Date: [isabelle] SMT 2021 Workshop: Final Call for Papers
- Previous by Thread: Re: [isabelle] Datatype definition can be slow
- Next by Thread: Re: [isabelle] Datatype definition can be slow
- Cl-isabelle-users April 2021 archives indexes sorted by: [ thread ] [ subject ] [ author ] [ date ]
- Cl-isabelle-users list archive Table of Contents
- More information about the Cl-isabelle-users mailing list