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
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 avoi
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
===
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 fr
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 v
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 a
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 http://www.opengroup.org/onlinepubs/9539
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.
Unfortuna
Tom Lane wrote:
> Greg Stark 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 just go
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() fu
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,
> w
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
=
* Contains PostgreSQL extention
*
* PostgreSQL (poly@>point) operator is currently broken beyond a certain
* precision. This module provides a contains(poly,point) to use as a
* replacement.
*
* It addition it
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 ha
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=
Dimitri Fontaine wrote:
Paul Matthews 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 support for it
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 subsc
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
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 it
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
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
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. > 1.
23 matches
Mail list logo
