Re: [HACKERS] Slaying the HYPOTamus

2009-08-25 Thread Paul Matthews
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Greg Stark
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Tom Lane
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Paul Matthews
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Greg Stark
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Sam Mason
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Sam Mason
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread David Fetter
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 (

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Kevin Grittner
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; >>

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread David Fetter
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-24 Thread Paul Matthews
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-23 Thread Nicolas Barbier
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-23 Thread Magnus Hagander
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-23 Thread Paul Matthews
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-22 Thread Tom Lane
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

Re: [HACKERS] Slaying the HYPOTamus

2009-08-22 Thread Greg Stark
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