On 15-Jul-05 Michael Smith wrote: > Werner LEMBERG <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 15-Jul-05 Time: 18:11:27 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list [email protected] http://lists.gnu.org/mailman/listinfo/groff
