happy_birthday++;
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dimitri Fontaine wrote:
Hi,
I've been idly thinking about binary COPY and recent performance efforts
spent on it. The main problem I have with binary output is that I never
know when it'll be any useful (except very same hardware and PostgreSQL
setup)... useful meaning I get to read it back
Another attempt at replacing the current HYPOT macro with a much better
behaved function. I've added comments addressing those sections of code
that tripped people up before. As well as explaining some of the design
decisions. Feedback appreciated.
Index: src/backend/utils/adt/geo_ops.c
Kevin Grittner wrote:
The first test seems unnecessary if you have the second.
x = 0, so x can't be zero unless y is, too.
Returning x on y == 0.0 will return 0.0 whenever x == 0.0.
-Kevin
Wish granted. :-)
--
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it.
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct these.
(The more little issue we eliminate, the more the large ones will stand
out.)
At line 3131
Tom Lane wrote:
I've applied the first three of these changes, but not the last two
(the 'dist' assignments). clang seems to have a tin ear for style :-(.
It's failing to notice that we have several similar code blocks in
sequence in these two places, and making the last one different from
Greg Stark wrote:
We're implementing things like box_distance and point_distance which
as it happens will already be doing earlier arithmetic on the doubles,
so whatever HYPOT() does had better be consistent with that or the
results will be just an inexplicable mishmash.
Let's look at
This is to go with the hypot() patch I posted the other day.
As other code, such as found in adt/float.c and adt/numeric.c, simply
assumes that isnan() exists, despite it being a C99 function, I have
assumed the same.
The below code should be placed into a file called src/port/hypot.c.
Greg Stark wrote:
Also, the question arises what should be returned for hypot(Inf,NaN)
which your code returns Inf for. Empirically, it seems the normal
floating point behaviour is to return NaN so I think the NaN test
should be first.
See
Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
If there's a performance advantage then we could add a configure test
and define the macro to call hypot(). You said it existed before C99
though, how widespread was it? If it's in all the platforms we support
it might be reasonable to
Like some ancient precursor to the modern hypot()enuse the dreaded
ill-tempered HYPOT()amus lurks in the recesses of geo_ops.c and
geo_decls.h. And many a line of code has been swallowed by its mighty maw.
This patch replaces the HYPOT() macro with a calls to the hypot() function.
The hypot()
Trying to solve this problem by using a process of elimination. All
works fine until the comment below is removed.
ALTER OPERATOR FAMILY box_ops USING GiST ADD
OPERATOR 1(box,point),
OPERATOR 2(box,point),
OPERATOR 3(box,point),
OPERATOR 4(box,point),
OPERATOR 5
Martijn van Oosterhout wrote:
I haven't completely understood what you're trying to do
Putting in place the missing 'box op point' and 'point op box'
operators. The problematic queries are at the bottom of the email.
- I don't see any definition of an operator class, just the family,
* replacement.
*
* It addition it adds the currently missing box to point operators, and
* conversly the point to box operators as well.
*
* (c) 2009 Paul Matthews. LGPL ?? .. (to be advised)
*===*/
#include postgres.h
#include u
I'm trying to add all the box op point operators. The C routines are
written and working as advertised. The manuals description of the
RESTRICT and JOIN clauses of CREATE OPERATOR don't seem too clear. Are
these samples correct, or am I totally off base here?
CREATE OPERATOR (
LEFTARG=
The story so far ... The provide polygon@point routine does not work
correctly when the points are close to the boundary. So we implemented a
custom contains(poly,point) function. In order to stop all points being
checked against all polygons, a separate bounding box is maintained. So
the query
Witting a box@point function easy. Having a spot of trouble trying to
figure out where and how to graft this into the GiST stuff. Could
someone please point me in the general direction?
Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Dimitri Fontaine wrote:
Paul Matthews p...@netspace.net.au writes:
Witting a box@point function easy. Having a spot of trouble trying to
figure out where and how to graft this into the GiST stuff. Could
someone please point me in the general direction?
You want index
marcin mank wrote:
You are correct, I think, though this does not solve the division problem:
As a first goal I'm just attempting to reduce the EPSILON from 1.0E-6
down to 1.0E-015 (give or take). The current regression test suite works
fine down to 1.0E-09. At 1.0E-10 errors appear, not in
Let us consider the ordering of real numbers in postgres. As you can see
from
the results below it has clearly returned the correct results.
select( 1. = 1.0002 ); = f
select( 1. 1.0002 ); = t
select( 1.
Tom Lane wrote:
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.
If the above statement was true, then the FP* macros should be extended
to
Tom Lane wrote:
No, I'm worried about code that supposes that it can divide by (x - y)
after testing that FPeq(x,y) is not true. point_sl() for instance.
We could perhaps fix those specific issues by testing the difference
explicitly instead of doing it like that. But there's still the
Paul Matthews wrote:
EPSILON in postgres is 1.0E-06
EPSILON for floats is 1.19209e-07
EPSILON for doubles is 2.22045E-016
Bad form to reply to my own post and all. If EPSILON for double
represented 1mm, then postgres is rounding to the nearest 10,000,000 km.
Since its only about
23 matches
Mail list logo
