[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3

From: Ludovic Courtès
Subject: Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3
Date: Fri, 07 Jun 2019 21:46:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Mark,

Mark H Weaver <address@hidden> skribis:

> I've found a way to efficiently support both immediate IEEE binary-64
> doubles up to ~1.158e77 (with larger ones transparently allocated on the
> heap), and also immediate exact rationals with up to 54 binary digits
> (~16 decimal digits), without restricting the 64-bit pointer space at
> all, and without any loss of arithmetic precision.

Woow, impressive, and really clever!

As Dave Thompson wrote on IRC yesterday, this can make a significant
difference for applications such as graphics and game engines.  I hadn’t
read the message yet and thought “hey, why not make instructions for
things like trigonometric functions so you get unboxed floats” but
obviously, as Dave pointed out, that wouldn’t scale well.  :-)

> Here's the format of fixrats on 64-bit systems:
>   Srrrrrrxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0111
>   |\____/\___________________________________________________/\__/
>   |  |                          |                              |
>   | rank (6 bits)             data (53 bits)                  tag
>  sign


> I chose this representation because it allows us to leverage existing
> floating-point hardware to efficiently pack fixrats.  Simply convert the
> denominator to an IEEE double, and now the rank will be in the low bits
> of the IEEE exponent field, immediately adjacent to the denominator with
> its high bit removed.  This simplifies the packing operation.

Fun.  :-)

Fixrats can make rationals more practical in applications where one
would have avoided them for performance.

IIUC, your plan is to have a different tagging on 32-bit platforms,
without fixflos, right?  I’m curious to see how much complexity would
entail from that.

I don’t know what Andy thinks, but if there’s a good way forward for
both 32-bit and 64-bit, it’d be a nice bonus for 3.0!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]