MIME-Version: 1.0
References: <56020530.4070302@clear.net.nz>
            <56025C88.6050307@morningstar2.co.uk>
            <CANQYN6xU9YatwHf3mT+CxzWOApEf9evuK1uNVatW2uPLoX2BRg@mail.gmail.com>
            <560465A8.2050901@clear.net.nz>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6w+7Bd0h--W8PnMitF+VAUKuv2SBzRDYEvYQ36W++h1HQ@mail.gmail.com>
Date:         Fri, 25 Sep 2015 10:54:24 -0400
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: An incomplete int-erface?
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <560465A8.2050901@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 9/24/15, Andrew Parsloe <aparsloe@clear.net.nz> wrote:
> On 25/09/2015 5:14 a.m., Bruno Le Floch wrote:
>> On 9/23/15, Joseph Wright <joseph.wright@morningstar2.co.uk> 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

I typically use l3benchmark, which is not on CTAN but can be found in
the l3trial directory (see
https://github.com/latex3/latex3/tree/master/l3trial/l3benchmark ).  I
never got back to working on it, but there are quite a few
improvements to be had.  Some day, perhaps, I'll have time and it can
be moved to l3experimental.

Bruno