<div dir="ltr">Right, I meant "exact" in the Racket sense of "exact rational." <div><br></div><div>The broader issue I'm thinking about is what kind of units to use in a typesetting system in order to get the best balance of precision and speed. </div><div><br></div><div>For instance, the flexibility of a 64-bit flonum doesn't necessarily buy you anything over a 64-bit fixnum, since typesetting systems have a practical limit on both precision (in the subpixel direction) and scale (in the megapixel direction). </div><div><br></div><div>TeX, for instance, is based on a "scaled point" which represents 1/65536th of a point, with a max dimension of 2^30 scaled points, or about 19 feet. One could imagine a 64-bit version of this concept that extends both the scale and precision (to ludicrous degrees) while remaining a fixnum (which I gather from the docs are typically cheapest).</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 1, 2014 at 2:01 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We should probably improve the contracts on `racket/draw` to promise<br>
flonum results for text metrics. The intent is to make metric-derived<br>
calculations have a predictable cost, instead of potentially triggering<br>
expensive exact arithmetic.<br>
<br>
When you say that Pango produces "exact" results, do you mean "integer"<br>
or "exact rational"? The latter is certainly true: Pango's raw API<br>
produces integers to be divided by 1024 to convert to drawing units.<br>
Taking that conversion into account, Pango doesn't always produce<br>
integer drawing units (at least on some platforms; I'm not sure about<br>
all). Even so, the intent is that representing an integer divided by<br>
1024 as a flonum will not normally lose any prevision (i.e., for normal<br>
drawing sizes), and so `inexact->exact` on the immediate result from<br>
`racket/draw` recovers the exact Pango result when exact arithmetic is<br>
specifically wanted.<br>
<div><div class="h5"><br>
At Mon, 1 Dec 2014 11:56:12 -0800, Matthew Butterick wrote:<br>
> The `get-text-extent` method in racket/draw does not contractually guarantee<br>
> either exact or inexact numbers, though in practice I find it produces inexact.<br>
><br>
> This function, however, calls into the Pango text-layout system. I find that<br>
> when I invoke Pango's text measuring directly through the FFI, it produces<br>
> exact results.<br>
><br>
> Is this difference in behavior deliberate, or does `get-text-extent` preserve<br>
> exactness under certain circumstances?<br>
><br>
><br>
</div></div>> ____________________<br>
>   Racket Users list:<br>
>   <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div>