## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: An incomplete int-erface?

From:

Date:

Wed, 23 Sep 2015 09:02:16 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (66 lines)
 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) }. 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 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. > > (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. 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. 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. BTW, as far as I know there is nothing that would be valid for an int expr. that would fail for l3fp. Joseph