Feedback on hypot and hypot2

Jens Nockert jens at
Tue Aug 14 04:32:39 PDT 2012

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.


On Aug 14, 2012, at 11:14 AM, Andrea Giammarchi wrote:

> I think these things are really easy to implement and fast enough in current JS engines, e.g.
> function cube() {
>   return, cube.iterator, 0);
> }
> cube.reduce = [].reduce;
> cube.iterator = function (p, c) {
>   return p + Math.pow(c, 3);
> };
> alert(cube(2, 3)); // 35
> br
> On Tue, Aug 14, 2012 at 9:26 AM, Herby Vojčík <herby at> wrote:
> Hi,
> 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).
> Herby
> Allen Wirfs-Brock wrote:
> 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:
> <>
> Allen
> On Aug 13, 2012, at 2:16 AM, David Bruant wrote:
> Hi,
> 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]
> [2]
> [3]

More information about the es-discuss mailing list