You really like the LaTeX3 FPU, don't you :-)

Perhaps we need to ship a big-integer module for expl3 to handle these cases :-)

It is a honor for xintexpr to relay l3fp beyond 16 digits of precision... for people not otherwise needing \xintexpr it is enough to only load xint rather than xintexpr and then \oodef\temp{\xintiiAdd{\twoback}{\oneback}} rather than \fdef\temp{\xintthe\xintexpr\twoback+\oneback\relax}. For people who wonder: \oodef and \fdef are wrappers around \def, defined in package xint, they apply some type of expansion to the argument of the macro, in the case at hand it achieves the same result as if using \edef, with a minuscule gain in time.

thanks... in my previous comment I mistyped \xintexpr where your original and correct \xintiiexpr was meant, sorry. I did some additional work on \xintexpr in June, and your comment encourages me to work towards releasing it sometime soon.

@jfbu I was serious about a 'bigint' module for expl3: I might take a look at your code if you've sorted expressions (we have single big ints but not expressions, and the latter would be nice for symmetry). Note of course the like most FPUs l3fp doesn't claim or aim to go beyond a certain number of places of precision.

To be clear, I'm thinking of expressions of the same form as allowed by \numexpr (and so \int_eval:n), not any further 'stuff'.

@JosephWright currently \xintiiexpr works with big ints, +, -, * and maps therein / to the Euclidean division (which truncates; rounding could be chosen instead). But it has more stuff than \numexpr: it knows ^ for power, it has max and min also gcd and lcm for multiple arguments, it knows sqrt for truncated square root... it knows boolean operation (development version uses && and || notation like in l3fp). Although only macros from xint are needed, \xintiiexpr is in package xintexpr which loads all the extra stuff in xintfrac dealing with fractions.

@jfbu Yes, I'd seen that xintexpr covers many things. What I was trying to get at is that for an expl3 implementation, expressions would be nice but would presumably be set up to match what can be done by (most obviously) \numexpr. That means on +, -, * and / as 'native' operations, with / rounding and a separate \bigint_div_truncate:n. [I'm thinking we should look at this for expl3 as the idea is we are aiming to cover what people commonly need in programming, and I need big integers for siunitx :-)]

@JosephWright (side note: development version has some new style when expandably branching which will make the code more readable.) Does bigint module for expl3 want as Heiko's bigintcalc or my xint deal with arbitrarily big integers, or say, up to 64 or 96 digits?

@jfbu (I've moved this to chat as it's not really about the question!)

@jfbu At the moment, we've got a bigint module just for some 'fun stuff' Bruno wanted to do

Presumably we'll need arbitrary sized integers for the same reason Heiko needs them: some PDF operations

For myself, siunitx is supposed to be able to handle arbitrary input but at present there are a few limits, which again I'd like to fix and need bigints limited only by memory

Of course, the team as a whole might not want to add anything at present, but perhaps I can get it into l3experimental for 'testing'

@JosephWright I changed some things in June in the code for \xintexpr ; the CTAN version tries to do things with braces which I have now completely removed. CTAN version knew only to handle single letter operator like & and |, now I do as in l3fp with && and ||, etc..

@jfbu Like I say, I suspect not an issue: I'm not trying to steal your users, just to add more 'standard stuff' to expl3 as the usefulness becomes apparent

@jfbu So for an expl3 module I don't see us needing || for big integer calculations, as we don't do that for 'normal' ones

@JosephWright if I manage to put myself into the code again, I will have a clearer view (I did not look at it since June, when I was in the mist of doing dummy variables) and will get some feeling for how much work it would be to stream down the xintexpr thing to only numexpr like abilities

@jfbu I'm thinking of getting Bruno to do it for us: he likes this sort of thing :-)

All I have to do is talk him into it

@JosephWright Bruno's l3fp is amaing

@jfbu Yes

@JosephWright routines of xint could be made more efficient if it was known in advance that say, we work with up to 128 digits only.

@jfbu I can see that: like I said, I suspect this is only really worth doing if you leave things open-ended

@jfbu I have much the same in siunitx with some operations: if I could be sure of the size they would be easier

I got a bit demoralized when I saw the time taken for multiplying out big integers with 1000 digits. With 100 digits it is ok, and I was happy. But that about the upper limit where things stay feasable if you expect to do many operations in the same document

@jfbu Documenting 'things get slow' is fine, in my opinion

@jfbu xint is very impressive, so I wouldn't worry too much

\xintexpr uses intensively \csname..\endcsname, hence the hash table gets impacted

@jfbu Ah

@jfbu I'll discuss with Bruno

yes, each elementary operation is done inside a \csname, to get only one token to shift around.

this is why there is a mechanisme \xintNewExpr to convert an expression with parameters into a giant macro which has nil impact on hash table

This \xintNewExpr mechanism, I rewrote entirely in development version.

@JosephWright by elementary operation I mean something like 23535665+28279287, not the details of the sub-operation, this gets transformed into \csname .=\xintiiAdd{23535665}{28279287}\endcsname thus the hash table gets filled with many undefined control sequences such as \.=2819038010

@JosephWright I am afraid this \xintexpr aspect could be a big impediment for serious consideration of doing something in his style for a biging expl3 module.

@jfbu Yes, I can see that

@jfbu I'll get Bruno on it if I can (he's busy nowadays as a recently-married man, but I can do my best)

Is it time for me now that I am a no-op on LaTeX3?? but I know Bruno (congratulations) will have no problem reading my code... (and get horrified by its lack of documentation and general style...)

@JosephWright I meant to say "time to reveal I am a no-op in LaTeX3 language"

@jfbu We still need a good guide to the language: egreg is meant to be working on one, I believe

I owe a debt to l3fp documentation, it contained a description of the issues related to expandably parsing expressions which helped me get started.

@JosephWright some parts of xint code will become more readable in next release; I have a new style of expandably choosing among code branches.

@jfbu Cool

Unfortunately I learned my trade while writing xint, hence It got not started on a strong basis of readability and documentability. And then, it's very costly to go back and rewrite earlier code...

@jfbu I know the feeling: texdev.net/2014/09/18/reworking-and-exposing-siunitx-internals

There are some limitations in \numexpr: \numexpr -(1)\relax is illegal for example, do you expect to maintain this in expl3 bigint module?

@jfbu I'd have to think about that, to be honest

@jfbu Probably some minor variations would be OK provided they are known

Hello @egreg

@JosephWright also,\the \numexpr 2(1+1)\relax is a bit surprising as the first ( terminates the expression. Thus no error is issued but 2(1+1) is printed.

Just peeking.

@JosephWright nice blog you have there. I read your "case-changing" post, for general culture...

@jfbu Incorrect syntax for multiplication. ;-)

@jfbu Cool

@egreg yes, but not in xintexpr! tacit multiplication...

@jfbu I'd leave * mandatory.

@jfbu I suspect it's quite easy to go either way

@egreg We've not in the fp module but there are reasons: for integers I'd agree

@egreg I take it you too want me to bother Bruno

@JosephWright When did he marry?

@egreg Earlier this year: Frank went to the wedding

@JosephWright And, more important, did he finish his PhD?

@egreg Not that I know of yet

I'll leave you to your big integers. ;-)

@JosephWright \numexpr is coherent as it also makes illegal \numexpr 2\dimen0\relax and wants \numexpr 2*\dimen0\relax

@egreg bye

@JosephWright but in \dimexpr, \dimexpr 2\dimen0\relax is legal while \dimexpr 2*\dimen0\relax is illegal

@JosephWright if it is not too indiscreet, what kind of PhD is Bruno working towards?

@jfbu Inherited from TeX's approach to dimensions, and a bit tricky but survivable

@jfbu Some kind of physics :-)

Ah, that's serious stuff...

@jfbu arxiv.org/a/lefloch_b_1

@jfbu perimeterinstitute.ca/people/bruno-le-floch

@JosephWright D-Branes in string theory, more than serious, at least he is a theoreticain he is not going to create a mini black hole at CERN which will swallow us all :-)

@JosephWright I hope to get back soon to xintexpr code and wrap up next release. Then I will be better armed and I guess I can extract a version minimally extending \numexpr and possibly make it an independent package, getting rid of superfluous stuff. Nice talking with you. bye.