[Dev-luatex] A design philosophy question...

David Kastrup dak at gnu.org
Tue Apr 3 13:20:08 CEST 2007


Taco Hoekwater <taco at elvenkind.com> writes:

> David Kastrup wrote:
>>
>> Anyway, is something like that an area that LuaTeX would actually ever
>> consider touching?  
>
> Perhaps one day, but definately not soon. There are a few ways out
> of this, but they all require dimens to occupy more than 32 bits
> internally, a step not to be taken lightly.

Not at all.  For fixing rounding of the units, the following patch
should do it:

Index: luatex.web
===================================================================
--- luatex.web	(revision 382)
+++ luatex.web	(working copy)
@@ -11570,7 +11570,7 @@
 @.sp@>
 else @<Complain about unknown unit and |goto done2|@>;
 cur_val:=xn_over_d(cur_val,num,denom);
-f:=(num*f+@'200000*remainder) div denom;@/
+f:=(num*f+@'200000*remainder+(denom div 2)) div denom;@/
 cur_val:=cur_val+(f div @'200000); f:=f mod @'200000;
 done2:
 

This has a chance for overflow if num+1.5*denom exceed 32768.  For the
new proposed ratios of nc and nd (and the old ones overflow, anyway)
and the traditional TeX ratios, this is not the case.

That's all it takes to make expressions with units round.  The
rounding is rounding up in ambiguous cases (only possible with even
denom).  Implementing round to even would seem like too much work
since we don't have the error propagation phenomenon of floating point
arithmetic to deal with.  And reducing TeX's bias by a factor of 1000
or more seems to be good enough.

Anyway, this would make "72.27pt" the same value as "1in".  Which was
what this was all supposed to be about.  Only that I wanted to check
that I did not break anything, and things were broken already.

-- 
David Kastrup


More information about the dev-luatex mailing list