Re: Fixing geometic calculation

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: Fixing geometic calculation
Дата
Msg-id 20090807163003.GL5407@samason.me.uk
обсуждение исходный текст
Ответ на Re: Fixing geometic calculation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fixing geometic calculation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Aug 07, 2009 at 11:40:58AM -0400, Tom Lane wrote:
> Sam Mason <sam@samason.me.uk> writes:
> > I would agree with Paul that EPSILON is a hack and probably should be
> > removed.
> 
> It's a hack but it's dealing with an extremely real problem, namely
> the built-in inaccuracy of floating-point arithmetic.  You can't just
> close your eyes to that and hope that everything will be okay.

Yes, I know it's a fiddle to get right.  Choosing the right primitives
is generally the most difficult part.

> A quick look through the geometry sources says that we might not be
> critically dependent on anything except the assumption that two values
> that aren't FPeq() will have a nonzero difference.

Sorry, I'm struggling to parse that.  I think it's all the double
negatives.  Are you saying that HYPOT() should really return zero when
it's currently giving back would be FPzero?

> (If you think this
> is a tautology, you don't know enough about floating point arithmetic
> to be qualified to offer an opinion here...)

I think I have a reasonable idea about FP arithmetic, I have had to
worry about rounding modes and such like before.  Never tried to write a
FP emulator though so I'm sure I could know more.

--  Sam  http://samason.me.uk/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: slow commits with heavy temp table usage in 8.4.0
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: slow commits with heavy temp table usage in 8.4.0