# Re: GnomeCanvasLine

• From: Gustavo Joćo Alves Marques Carneiro <ee96090 fe up pt>
• To: Jon Trowbridge <trow emccta com>
• Cc: Lauris Kaplinski <lauris ariman ee>, gnome-devel-list gnome org
• Subject: Re: GnomeCanvasLine
• Date: Thu, 4 May 2000 19:19:23 +0100 (WEST)

``` - Function: double hypot (double X, double Y)
- Function: float hypotf (float X, float Y)
- Function: long double hypotl (long double X, long double Y)
These functions return `sqrt (X*X + Y*Y)'.  This is the length of
the hypotenuse of a right triangle with sides of length X and Y,
or the distance of the point (X, Y) from the origin.  Using this
function instead of the direct formula is wise, since the error is
much smaller.

You're right. I assumed (wrong) that to have a function like hypot
had to be because it would be optimized. I confused it with other
functions like  sincos, which are in fact provided for eficiency. I
apologize for my mistake.

On Thu, 4 May 2000, Jon Trowbridge wrote:

> On Thu, May 04, 2000 at 01:34:18PM +0100, Gustavo Joćo Alves Marques Carneiro wrote:
> >   Ok. I'm a bit convinced. But maybe one could use hypot where available,
> > which is a function that calculates srqt(dx*dx + dy*dy) in a faster way. I
> > think it's a GNU extension.
>
> Since we've descended into total trivia here, I'll just point out that
> (on my system, at least) hypot is (essentially) defined as
>
> #define hypot(x,y) sqrt(x*x+y*y)
>
> It is actually defined by inlining the appropriate code, not by just
> standard macro expansion, but for all practical purposes the results
> are the same.
>
> One upon a time a separate, optimized, hypot() call might have made
> sense, but not anymore.
>
> If anything, hypot should use a different algorithm because computing
> sqrt(x*x+y*y) can be numerically unstable --- but that is an entirely
>
> -JT
>
>

--
Gustavo J.A.M. Carneiro
[reinolinux.fe.up.pt/~ee96090]

```