MIME-Version: 1.0
References: <56020530.4070302@clear.net.nz>
            <56025C88.6050307@morningstar2.co.uk>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6xU9YatwHf3mT+CxzWOApEf9evuK1uNVatW2uPLoX2BRg@mail.gmail.com>
Date:         Thu, 24 Sep 2015 13:14:28 -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:  <56025C88.6050307@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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