Re: [Groff] Horizontal rule w/ length a fraction of the page wid

[Ted Harding]

On 15-Jul-05 Michael Smith wrote:
> Werner LEMBERG <address@hidden> writes:
>> To overcome all those limitations I suggest that you say this:
>> 
>>   \l'\n(.lu*80u/100u)
>> 
>> avoiding fractional numbers.
> 
> Thanks! That works perfectly (with an apostrophe in place of the
> closing paren, which I guess was just a typo, right?).
> 
> So, in general, for computations involving numbers less than one,
> is the right way to specify them always as a fraction instead of a
> decimal number? How about for fractional numbers greater than one?
> 
> Sorry if I seem clueless -- but the groff info doc and man pages don't
> seem to provide much guidance about fractional numbers. At least not
> that I could find. Maybe I'm not looking in the right place.

It can get ricky. As far as I know, groff still maintains the
original troff rule that arithmetic in requests is done in
integers (even though you can include fractional numbers as parameters
to requests, such as ".sp 0.8m").

Also, while you can force precedence by parentheses, arithmetic is
done be evaluating from left to right, so that

  1+2*3 = 9 and not 7

To come back to the "fraction of line length" issue, if LL = 6 inches
then \n[.l] will return 6*72000 = 432000 (if you're using PostScript).
This of course is in "device units". Incidentally, you can always test
how things will come out by interpolating "\\n[whatever]" in a test
document, so that for instance

  The line length is \n[.l] units

will render as

  The line length is 432000 units

That's already quite a large number, and you have to be careful
that your arithmetic does not introduce even larger numbers when
you multiply, and cause the arithmetic registers to overflow, so
the order of operations can matter. The largest number you can
multiply a \n[.l]=432000 by is 4971; after that it overflows
and you get 0.

For this reason, a conservative version of

  \l'\n(.lu*80u/100u'

is

  \l'\n(.lu*8u/10u'

(\n[.l]*8 is a smaller number thatn \n[.l]*80) or, even safer,

  \l'\n(.lu/10u*8u'

since then you first make a number smaller than the original,
and then a bigger one which is still smaller than the original.
(Note that "left to right" evaluation ensures that this is
what happens). Not that it matters in this case, since you're
using small multipliers (less than 4971), but it could if you
use large multipliers on bigger numbers.

The largest integer you can have in groff is

  2147483647 = 2^31 - 1

and you can work out from this why 4971 is the largest multiple
of \n[.l]=432000 that you can allow yourself.

But -- see below!

Another thing to bear in mind is what's going to happen to
"lost fractions", i.e. the remainders after division.

As far as groff is concerned, 20/7 = 2, the remaining 6/7
being dropped.

In the above example this is not going to matter, since 1 point
is 1000 units, and even if you wanted a fraction 7/9 of the
line-length the result of

  \n[.l]u/9u   or of  (\n[.l]u*7u)/9u

is going to be wrong by a maximum of 8/1000 points. However,
if you do it in the order

  \n[.l]/9u*7u

then you could be out by (7*8)/1000 points. This is still
rather imperceptible in real life, but it makes the point,
and in a different context it could matter visibly.

But there are no absolute rules for all occasions. You have
to think about the magnitude of what can happen.

Best wishes,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 15-Jul-05                                       Time: 18:11:27
------------------------------ XFMail ------------------------------