Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by h1439878.stratoserver.net (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t8OL89Hx028299 for ; Thu, 24 Sep 2015 23:08:10 +0200 Received: from relay2.uni-heidelberg.de ([129.206.119.212]) by mx-ha.gmx.net (mxgmx110) with ESMTPS (Nemesis) id 0M0dCk-1aXjsT2IyE-00usWi for ; Thu, 24 Sep 2015 23:08:03 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t8OL6HM0029574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 23:06:17 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t8OJBJcQ027157; Thu, 24 Sep 2015 23:06:16 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 12580921 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 24 Sep 2015 23:06:16 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id t8OL6G3Y008061 for ; Thu, 24 Sep 2015 23:06:16 +0200 Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id t8OL66gi015242 for ; Thu, 24 Sep 2015 23:06:09 +0200 Received: from mxin3-orange.clear.net.nz (lb1-srcnat.clear.net.nz [203.97.32.236]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0NV700BTX9783740@smtp3.clear.net.nz> for LATEX-L@listserv.uni-heidelberg.de; Fri, 25 Sep 2015 09:06:03 +1200 (NZST) Received: from 118-92-68-230.dsl.dyn.ihug.co.nz (HELO [127.0.0.1]) ([118.92.68.230]) by smtpin3.clear.net.nz with ESMTP; Fri, 25 Sep 2015 09:05:45 +1200 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Antivirus: avast! (VPS 150924-1, 25/09/2015), Outbound message X-Antivirus-Status: Clean References: <56020530.4070302@clear.net.nz> <56025C88.6050307@morningstar2.co.uk> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Message-ID: <560465A8.2050901@clear.net.nz> Date: Fri, 25 Sep 2015 09:05:44 +1200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Andrew Parsloe Subject: Re: An incomplete int-erface? To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:nMu9zZsLOX0=:oN5xlwU/oU5yW4jHumasUlj6i2 f1Tb3zHfR9GJqS1i2nD26l93oDa3r0zbqN1AvYPCl+uiFnUyPzAAbRW//rRssl8EMWkzp4lHa 3LZZhCa7RJrr3iDq4HbBq47PsEpAFeFF0UkSnfq66WQYpyiC0mkT4jU3n+rdfKVYTmscuMkhj +LyZe+/CrtHiJYWWZelcTSi+Fxmd2bjRzQebvhi+0cgAN3sKveMooR+R4MlSkCu3wmkcFjxGr R+sfkBCnlEb8pE/RMJDzl6YmwvPxfTvlmG1Jd5XGdhcEHwz0hTiOs0agM81akHHS8QnxkNB6c uKo0Be+WG8km75JwaKgweMCttoIpYNt+CvajePK1Vi29BQKg6CVnakvCIaX2awgoNwkekaiN5 6Je5TlOSEm73mC/NVyQl1TmPrwYp487U57htF6t9IeSO8LcWTng0pzD+e3w2cwXQRjMIeQ6UK PWxLpeF3u7unMhPhNHySwL8ACryr8KQpdr+uGRuiSVE0bEr64eWNHbvSS3nL4a26vRcml0wBr BJUVC0+Kvrt4D+4rf+gSBGkbcFi92ufcknRy760jcJTvSB9doup1nS+eZEA2L8Wql4mpX0m6L Pe4sdo24SCWapHY5rLHw284lYAZC7ek0AesP9Px6mXN7s8XHal4blcp3KuItXo9N7tYvaXhio /fSCR6//zGCr2CAAfFg/oTrLjYPLHuwlA37wpXRA/ReUHAz7mRZv9g+dGtGfpWhn5vYBNWPbD wOwvh440jZShQIc1dEZHVs6OAqf71D7BEMvMyVScGecrxj94qVFqYXximQcu5MArZOyfAt8rN gb78JhZDJxHISDlOY5gQrJdFJnyhJbPdoFVfEPBFjHxQtr+W0W3Zjkva5ZI7ZwduZWGxl/dgy /Bc1aSZyHkz0hYowVlCntBrgB7Zk8A28zcgGtrx7qhSsuhviG3hl8+rA8D0684NKSFQusNsOg Vbo56LatR2adbSAMaEHXkZMEuDbw9tHnG6L71Wq6Eqe8kHGkZe6kp6+iVlyf9Bl6Aq7pBkef4 ExEo++InTGkfynN60ATnhLeDmqK8e2GxteuNTk+dt1+G87BvphkfZ8pDQIUdz54g9bzoonPvG mBKhgRA+SSuZrS3F7/5qBRYjQxUrJvBXMjr4aZmnH1CTWCOdxDp7G6gOxchTc/od4x1FclLEl 3K03PJs+1AAjK5k6thKrDKog9CbsNUdUWPLmOZIbuNmftI9Btjo5CC9TWrusDd1wxb2d4gd1L 6fxOuEAaxezm36pt7Lgctc0YAOAJDLXQgJTvpHnYw7G4YhNwD+GPyzc4LSVstOWefgCcduCHM fJfNkK1zTtwWwGh6DVwgYpNXvVa5eC+l0iXTmigIu9CuhPyDGuwdrLKnE0vw3WO4NFuchSdKU tKRmBG82hLP36zl0hDTuYOmBk+4RnASqFNFVsei676EvaIJw8fl5zh8BOWkR9/wxPyw+Sd+lU vCiwMYMd1+PVpcI3nfANuV7dmhUbxkQ69vZBgdlxlKq4qgvQjR X-UI-Loop:V01:zZe7XrtN5l4=:GLBiwI9d7bx0sXkhH5Gyq5Aa8bUoZrAw8qsmUJUWySk= X-UI-Out-Filterresults: notjunk:1;V01:K0:k7dHgBucAQo=:8iFMAr/geWRcWuwhIBAeA3 ZM5EKMVWID+J0fMo4+h9A8MBuwIp0KyRz0sxSR4+1UbvGKAhL8tOLMn//vOI9xuhMGeieGzIw yfpT6sy+z/iBGo88cd+6R5kKW/ZzVxjXvOEN7U1eoGBiEIw/uFMQqco6X9NQar7XHLozaYj4D +vJufWC/HL+OrP+X1OkadiazrHuKGy0e90o+26LSYI/q+6npVcTOQm1o2/iUnql9tWBCaWyGl A4w+Zu3w4nHEJnutuB0hKBcrBcB2AxB4WgSw9EEI+rR+eNTOPWsXg56VWj966sbIClfAzyNu5 Iz1ubr0/ErGz+r1N1IymOeyiC19AAVlJRfmfaxCpefgDrudj3cDXgW76OxBBfgzJ1xbLapsPr LTI7+IaqDG4wdWkGfBUhS6ttHGfXnZuLjZqXyqIMTmOqIkTjHJGr6UfW7ZOP4t0oXDB+W+NN9 VGNXwSLpm1OaHplc7fgEaeaiCbDmLzkz6LgXbKScDspD/Qm1GJsE X-Scanned-By: MIMEDefang 2.71 on 85.214.41.38 Status: R X-Status: X-Keywords: X-UID: 7892 On 25/09/2015 5:14 a.m., Bruno Le Floch wrote: > On 9/23/15, Joseph Wright wrote: >> On 23/09/2015 02:49, Andrew Parsloe wrote: >>> \int_eval:n { - (1+2) } >>> >>> gives a "Missing number, treated as zero" message. So does \int_eval:n { >>> + (1+2) }. > As Joseph says, this is due to the syntax of eTeX's primitive \numexpr. > Let me answer Will's suggestion of adding "0+" to the start of every > \int_eval:n. That won't cover cases such as \int_eval:n { 1 + ( - (2 > + 3) + 4) * 5 } where the "-(" construction (with no left-hand > operand) appears in the middle of an expression. > >>> But >>> >>> \int_eval:n { 0 - (1+2) } >>> >>> evaluates correctly. If + ( or - ( are the first members of an integer >>> argument, an error results; if they are not the first members, they are >>> accepted by \int_eval:n etc. I don't know that this is a bug as such but >>> it certainly feels to me like an untidiness in the l3int interface. It >>> means that the order in which component parts of an expression are >>> presented to \int_eval:n matters, even though in an arithmetical sense, >>> they evaluate to the same number. > I agree that it would be better to have a nicer interface, and it is > very close to being a bug, but one in eTeX rather than LaTeX3, and not > fixable on our end. > >>> I query too whether an expression like >>> >>> \int_eval:n { 3(1+2) } >>> >>> should "evaluate" to 3(1+2), rather than 9, without showing an error. > That we could catch. Heiko once suggested that we include parentheses > in our expressions, defining \int_eval:n {#1} as \tex_the:D > \etex_numexpr:D (#1) \tex_relax:D . That would at least produce an > error when an expression is terminated early (say because of a ^ or > juxtaposition, or space in the middle of a number, etc). > > Of course that wouldn't help with unbalanced parentheses. > >>> (Alternatively, I find myself wondering what would be entailed to >>> harmonize the integer interface with the fp one (which has no problem >>> with these expressions)? Then one could choose whether to evaluate an >>> expression involving integral numerals in l3fp or l3int without having >>> to change the expression, as one does at present. For instance, if the >>> expression involves an exponent, use l3fp; if not use l3int. This choice >>> becomes more complicated when the expression itself needs to be changed.) >>> >>> Andrew >> The different 'behind the scenes' here is that \int_eval:n is just the >> engine \numexpr primitive in a macro wrapper, but \fp_eval:n is >> implemented entirely in macros (as there is no floating-point >> primitive). Thus while we can alter the parser for fp work, we can't for >> int work, or rather not without significant changes. In particular, >> there would be a performance implication in parsing int input and doing >> the calculations 'by hand'. I suspect int parsing would be easier than >> for fp expressions, but even so this looks like a significant effort. > I would expect at least a 10x slow-down (rough estimate, I can look > into this more if requested). > >> As Will has commented, we might manage at low cost to avoid the bracket >> issue, but allowing \int_eval:n { 3(1+2) } would be rather more tricky. >> Indeed, I'd probably say we shouldn't: here I think requiring an >> explicit "*" is the right approach. Bruno is best-placed to comment on >> the fp implementation here. > I actually fear that I probably made a mistake when allowing > juxtaposition of this kind in l3fp. Maybe it is not too late to > change. We never really had time for a discussion of the syntax of > l3fp, which I cooked up myself with no outside input. > >> The reason I'm wary of making any changes, quite apart from effort both >> in terms of the team and in terms of TeX when using expressions, is that >> life gets more complex when you look at dim/skip/muskip cases. There, >> the underlying primitives have particular requirements, thus >> >> \dim_eval:n { 4pt * 3 } >> >> is valid but >> >> \dim_eval:n { 3 * 4pt } >> >> is not. I really don't think we want to implement all of the necessary >> parsing for this by hand, so saying that we follow the underlying >> primitive requirements is a position I think we are best with in general. > Yeah, getting this \dim_eval:n to work would require pretty much as > much work as fp parsing. The code is mostly available but I would > expect something like a 100x slow down. > >> BTW, as far as I know there is nothing that would be valid for an int >> expr. that would fail for l3fp. > That is true, so any int expression can be turned into an fp one if > you realize that you want to use ^ for instance. The reverse is not > true. > > Bruno > Thank you all for your replies, which fill in the background for me. I have been using l3fp intensively for a while, but have only recently started using l3int in earnest, at least in part for the presumed performance gain, when these particular issues have arisen. (Looking at those references to 10x slow down, or 100x slow down, might there be room in l3kernel or l3packages for an l3timer module?) Andrew Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus