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
On Tue, Aug 25, 2009 at 1:14 AM, Tom Lane wrote:
> Paul Matthews writes:
>> Just trying to implement correct C99 behaviour here.
>
> Around here we tend to read the Single Unix Spec before C99, and SUS
> saith something different:
It doesn't seem to anticipate NaN at all.
Neither of these seems
Paul Matthews writes:
> Just trying to implement correct C99 behaviour here.
Around here we tend to read the Single Unix Spec before C99, and SUS
saith something different:
http://www.opengroup.org/onlinepubs/007908799/xsh/hypot.html
It would be serious folly for us to suppose that every platfo
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
On Mon, Aug 24, 2009 at 6:52 PM, David Fetter wrote:
> double hypot( double x, double y )
> {
> double yx;
>
> if( isinf(x) || isinf(y) )
> return get_float8_infinity();
>
> if( isnan(x) || isnan(y) )
> return get_float8_nan();
For what it's worth though, check out the code in float
On Mon, Aug 24, 2009 at 06:59:38PM +0100, Sam Mason wrote:
> > On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> > > if (x == 0.0)
> > > return 0.0;
> > > else {
> > > yx = y/x;
>
> is preventing a divide by zero on the line above. So it's not a
> performanc
On Mon, Aug 24, 2009 at 07:07:13AM -0700, David Fetter wrote:
> These next two lines are a teensy bit baroque. Is there some
> significant speed increase that would justify them?
Just noticed with your revised code that the following check:
> On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthe
On Mon, Aug 24, 2009 at 12:47:42PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
> > On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
>
> > These next two lines are a teensy bit baroque. Is there some
> > significant speed increase that would justify them?
> >
> >> if (
David Fetter wrote:
> On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> These next two lines are a teensy bit baroque. Is there some
> significant speed increase that would justify them?
>
>> if (x == 0.0)
>> return 0.0;
>> else {
>> yx = y/x;
>>
On Mon, Aug 24, 2009 at 11:14:19PM +1000, Paul Matthews wrote:
> 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.
>
> Th
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
2009/8/23 Magnus Hagander :
> For another data point, Microsoft documentation says:
> "This POSIX function is deprecated beginning in Visual C++ 2005. Use
> the ISO C++ conformant _hypot instead."
>
> _hypot() has been there since Windows 95, so it shouldn't be a problem
> to use it - it just nee
On Sun, Aug 23, 2009 at 07:42, 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
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
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 with it.
For one data poin
On Sun, Aug 23, 2009 at 4:54 AM, Paul Matthews wrote:
>
> The hypot() function has been part of the C standard since C99 (ie 10
> years ago)
Postgres targets C89. The date of the standard is when the standard
came out, it takes years before it's widely available and then years
again before the sys
16 matches
Mail list logo