# Feedback on hypot and hypot2

David Bruant bruant.d at gmail.com
Wed Aug 15 17:09:09 PDT 2012

Le 14/08/2012 04:16, Allen Wirfs-Brock a écrit :
> check out the current ES66 spec. draft.  Based upon discussions at the
> March TC39 meeting hypot2 was eliminated and an optional third
> argument as added to hypot.
Quoting relevant part of the March meeting notes [1]:
> Discussion of hypot, hypot2.
> hypot is the square root of the sum of squares and takes either two or
> three arguments.
> hypot2 is the sum of squares and takes either two or three arguments.
> Waldemar: How is hypot2 better than just doing x*x + y*y?
> Luke: It's just ergonomics.
> General reluctance about the hypot2 name because it looks like the 2
> means two arguments (as in atan2).  Some debate about other function
> names (hypotSq? sumOfSquares?).
> MarkM: How is hypot better than sqrt(x*x + y*y)?
> It's potentially more efficient and more accurate.  It is widespread
> in numeric libraries.
> Consensus:  hypot will support just two or three arguments.  hypot2 dropped.
Consensus here indeed.

> Waldemar, MarkM:  Why not one or zero arguments?  It would be 0 for
> zero arguments and abs for one argument.
> Allen, DaveH:  If you pass one argument to hypot, you'll get NaN.
> Waldemar:  Why isn't it variadic?
> Luke:  2 or 3 is the 99% use case.
> Waldemar:  2 or 3 arguments is the 99% use case for max.
> Waldemar:  If it's not variadic and takes only 2 or 3 arguments,
> you'll get silent mistakes.  If you pass in four arguments, you'll get
> the hypot of the first three, and the last one will be silently
I agree and it seems to be unadressed by the decision in the consensus,
is it?
If it's decided that hypot should only accept at most 3 arguments, then,
passing 4 or more args should return NaN (instead of making people hate
JavaScript more because of error hiding).
I however still believe having hypot variadic is more interesting, though.

> Luke:  Will go back to the experts to explore implementing variadic hypot.
Who/what does "the experts" refer to here?

> Note that the new function names such as hypot are generally selected
> to match the names from widely used c
>
I certainly missed the discussion where this choice was made, but does
C-matching matters?
For Math functions, I would tend to favor function names math folks are
used to, like the ones in Matlab (which I don't know at all, maybe they
map the C ones too).

Is the proportion of people who come to JavaScript from C using math
libraries (as opposed to people coming to JavaScript with any other
background) big enough to consider familiarity with C function names a
decisive argument for JavaScript function naming?

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-March/021919.html