Re: Range types - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Range types
Date
Msg-id 407d949e0912150509r2ef2ddc9y5f4fd68be2d5676c@mail.gmail.com
Whole thread Raw
In response to Re: Range types  (tomas@tuxteam.de)
Responses Re: Range types  (tomas@tuxteam.de)
Re: Range types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Dec 15, 2009 at 7:28 AM,  <tomas@tuxteam.de> wrote:
> The situation is even more restricted with floats (they are much
> smaller; thus one could say that they're more "discrete" than strings,
> even). Problem with floats is -- the granule is not the "same size" over
> the whole range (nasty), and it's all implementation-dependent
> (nastier). But given an implementation, the concept of "next" and
> "previous" on floats is (if you give me some slack with NANs) mostly
> well-defined

In fact, as I only recently found out, one of the design goals of IEEE
floats was specifically that they sort lexicographically and use every
bit pattern. So you can alwys get the "next" float by just
incrementing your float as an 64-bit integer. Yes that raises your
value by a different amount, and it's still useful.

-- 
greg


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG patch 4.1, out-of-scope cursor support in native mode
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPG patch N+1, fix auto-prepare