LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Fri, 25 Sep 2015 09:05:44 +1200
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=utf-8; format=flowed
Andrew Parsloe <[log in to unmask]>
text/plain (112 lines)
On 25/09/2015 5:14 a.m., Bruno Le Floch wrote:
> On 9/23/15, Joseph Wright <[log in to unmask]> 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?)



This email has been checked for viruses by Avast antivirus software.