On 10/4/2015 4:57 AM, Reinhard Kotucha wrote:
> On 2015-10-04 at 00:36:08 +0200, Hans Hagen wrote:
>
> > On 10/3/2015 3:06 AM, Reinhard Kotucha wrote:
> > > On 2015-10-02 at 17:11:35 +0200, Hans Hagen wrote:
> > >
> > > > going 64 bit internally in tex would mean a lot of checking and
> > > > patching of code
> > >
> > > Does it really matter whether a user specifies a number which is too
> > > large in his TeX input file or whether such a number comes from Lua?
> >
> > hard to say but sometimes tex packs data together so casts happen (many
> > internals are so called halfwords)
>
> Sure, but a number in a TeX input file is a string and TeX has to
> convert it to a number. Maybe it's possible to convert a Lua number
> to a string and feed it to TeX at a point where TeX expects a string,
> i.e. before TeX converts strings to numbers. It doesn't matter then
> how TeX stores numbers internally.
normally one would separate that: so we can have 64 bit at te lua end
and tex still being 32 bit (with truncated casts) .. one can already use
the token parser to pick up any sequence of characters and pass that to
lua and back ... so one can then store 64 bit numbers in lua instead of
in counters
> I must admit that it's difficult to decide whether 64 bit numbers are
> useful or not. But it would certainly be annoying if texlua can't
> read the xref table of a PDF file (10^{10} > 2^{32}). This seems to
> work even with Lua 5.1 on a 64 bit system but numbers with more than
> 14 decimal digits are converted to floating point numbers.
it's mostly that one needs to deal with cases like
123 / 2.0
vs
123 / 2
so all existing usage of lua (in macro packages) needs to be checked
when we move to 5.3
another option is 5.2 using metapost number libraries
> | $ lua
> | Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
> | > x=12345678901234
> | > print (tonumber (x))
> | 12345678901234
> | > x=123456789012345
> | > print (tonumber (x))
> | 1.2345678901234e+14
>
> Can anybody confirm that the output is the same on a 32 bit system?
>
> It's clear to me that Lua has to be frozen in LuaTeX former or later.
> But since LuaTeX can be considered "not stable" ATM I think that
> changes can be made more easily ATM rather than later.
sure, we will decide before we end up with 1.0 (after which we can again
experiment till 2.0, so maybe 5.3 is for luatex 2.0 as we can then adapt
some of tex internals)
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------