Discuss
  • Feedback on hypot and hypot2

Feedback on hypot and hypot2

# David Bruant (13 years ago)

I'd like to provide some feedback on the more math functions proposal [1] (and the most recent PDF at the top of the page) The hypot and hypot2 functions accept 2 or 3 arguments, but I don't see a reason why they wouldn't accept an unbounded number of arguments. Although the physical world can be accurately enough described in 3 dimensions, math folks sometimes think in abstract N-dimension spaces and compute euclidian distances in these spaces. JS Engines are still free to heavily optimize the common case of 2 or 3 arguments.

I'd like to talk about naming as well. "hypot" (for "Hypotenuse") is an accurate name for the 2 dimension case, but much less for 3 dimensions as far as I know (the English wikipedia page [2] doesn't mention the 3D case either) and even less for N-dimension. I think it would make sense to rename it. Maybe "euclidianDistance" (too long?), "distance" [3] (accurate mathematically, but may sound vague in the broader context of JavaScript), "eucl" (too cryptic?), other?

David

[1] harmony:more_math_functions [2] en.wikipedia.org/wiki/Hypothenuse [3] en.wikipedia.org/wiki/Distance#Geometry

# Christian Mayer (13 years ago)

Am 13.08.2012 11:16, schrieb David Bruant:

I'd like to talk about naming as well. "hypot" (for "Hypotenuse") is an accurate name for the 2 dimension case, but much less for 3 dimensions as far as I know (the English wikipedia page [2] doesn't mention the 3D case either) and even less for N-dimension. I think it would make sense to rename it. Maybe "euclidianDistance" (too long?), "distance" [3] (accurate mathematically, but may sound vague in the broader context of JavaScript), "eucl" (too cryptic?), other?

The correct mathematical name would be "norm".

And there are different ways a function could work and it still would be a norm (see this section on the wikipedia page you've posted: en.wikipedia.org/wiki/Distance#Distance_in_Euclidean_space; "norm" is a mathematical construct that gives a few guarantees: en.wikipedia.org/wiki/Norm_(mathematics))

Three norms are used quite often so they'd profit from a native function:

  • 1-norm (usually the fastest to compute)
  • 2-norm (hypot in the 2d case; usually the squared value is enough as well as faster to compute, so it's much more often used in numerical algorithms)
  • infinity-norm (the least used variant)
# David Bruant (13 years ago)

Le 13/08/2012 19:56, Christian Mayer a écrit :

Am 13.08.2012 11:16, schrieb David Bruant:

I'd like to talk about naming as well. "hypot" (for "Hypotenuse") is an accurate name for the 2 dimension case, but much less for 3 dimensions as far as I know (the English wikipedia page [2] doesn't mention the 3D case either) and even less for N-dimension. I think it would make sense to rename it. Maybe "euclidianDistance" (too long?), "distance" [3] (accurate mathematically, but may sound vague in the broader context of JavaScript), "eucl" (too cryptic?), other? The correct mathematical name would be "norm".

I'm glad we agree that "hypot" is inaccurate.

And there are different ways a function could work and it still would be a norm (see this section on the wikipedia page you've posted: en.wikipedia.org/wiki/Distance#Distance_in_Euclidean_space; "In the Euclidean space Rn, the distance between two points is usually given by the Euclidean distance (2-norm distance). Other distances, based on other norms, are sometimes used instead." Euclidean distance (aka 2-norm distance) definition maps the one of the function currently named "hypot", specifically computing the squareroot of the sum of squares, so I don't see how "norm" is more correct in that case than "distance".

"norm" is a mathematical construct that gives a few guarantees: en.wikipedia.org/wiki/Norm_(mathematics))

Three norms are used quite often so they'd profit from a native function:

  • 1-norm (usually the fastest to compute)
  • 2-norm (hypot in the 2d case; usually the squared value is enough as well as faster to compute, so it's much more often used in numerical algorithms)
  • infinity-norm (the least used variant)

It seems that what you're asking for is something different than the current hypot function definition.

# Allen Wirfs-Brock (13 years ago)

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.

Note that the new function names such as hypot are generally selected to match the names from widely used c libraries: docs.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdDBVcFZaMXhlY2d2RnM0TDVxLWlua3c&hl=en#gid=0

# Herby Vojčík (13 years ago)

what about adding square and cube functions which accept any number of arguments and return sum of squares/cubes? For one arg, they would just return square/cube as expected, for more they will sum them (for none return 0 of course).

# Andrea Giammarchi (13 years ago)

I think these things are really easy to implement and fast enough in current JS engines, e.g.

function cube() { return cube.reduce.call(arguments, cube.iterator, 0); }

cube.reduce = [].reduce;

cube.iterator = function (p, c) { return p + Math.pow(c, 3); };

alert(cube(2, 3)); // 35

br

# Jens Nockert (13 years ago)

For reference, there is a proposal for a DSP-library[1] for the W3C Web Audio API, that would solve a very similar 'problem' in a browser, it also covers most of the use-cases for the other variadic `Math' functions that are proposed.

function cube(sourceArray) {
  DSP.pow(tempArray, sourceArray, 3)
  return DSP.sum(tempArray)
}

If the only reason for these specialized methods are geometry processing &c in a browser for WebGL and so on, I think that you could just wait for these, or whatever eventually gets implemented in a browser instead? No need to add another version inside of `Math'.

Ps. Such an implementation of a variadic `cube' does not give accurate results depending on the input, it needs a better method for calculating the sum.

[1] people.opera.com/mage/dspapi

# David Bruant (13 years ago)

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 xx + yy? 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(xx + yy)? 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. Luke: It's not variadic. 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 ignored. That's bad.

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 libraries: docs.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdDBVcFZaMXhlY2d2RnM0TDVxLWlua3c&hl=en#gid=0

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] esdiscuss/2012-March/021919

# Allen Wirfs-Brock (13 years ago)

On Aug 15, 2012, at 5:09 PM, David Bruant wrote:

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]: ... 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. Luke: It's not variadic. 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 ignored. That's bad. 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.

All JavaScript built-ins accept and ignore unspecified extra arguments, so there is nothing out of the ordinary about ignoring a 4th augment. There is a significant difference between specifying that a function takes exactly 2 or 3 arguments and saying that it is takes an arbitrary number of arguments

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

presumably Microsoft' keeps warehouses full of experts

Note that the new function names such as hypot are generally selected to match the names from widely used c libraries: docs.google.com/spreadsheet/ccc?key=0Ak51JfLL8QLYdDBVcFZaMXhlY2d2RnM0TDVxLWlua3c&hl=en#gid=0

I certainly missed the discussion where this choice was made, but does C-matching matters?

matching precedent.

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?

I believe that the thinking was that people may be translating Math libraries or numeric code currently implemented in C/C++ into JS and that name familiarity would help.

# David Bruant (13 years ago)

Le 16/08/2012 04:40, Allen Wirfs-Brock a écrit :

On Aug 15, 2012, at 5:09 PM, David Bruant wrote:

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]: ... 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. Luke: It's not variadic. 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 ignored. That's bad. 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.

All JavaScript built-ins accept and ignore unspecified extra arguments, so there is nothing out of the ordinary about ignoring a 4th augment.

If authors can be confused into thinking the function legitimately accepts 4 arguments while it only takes 2 or 3, it seems out of the ordinary. parseInt ignores its third argument, but there is no obvious third argument to pass anyway. Math.max ignores no argument and legitimately so. hypot ignores all arguments beyond the third for no good reason.

There is a significant difference between specifying that a function takes exactly 2 or 3 arguments and saying that it is takes an arbitrary number of arguments

I agree, but I don't understand what you mean here. Is it an argument against the idea of defining a function that takes an arbitrary number of arguments? It's been done with Math.max and quite successfully so as far as I know.

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?

I believe that the thinking was that people may be translating Math libraries or numeric code currently implemented in C/C++ into JS and that name familiarity would help.

Ok, but I think my question still stands. People may also be translating Math libs from Matlab or any other math-oriented language. Why favoring C against Matlab folks?