On Fri, Oct 9, 2015 at 10:26 AM, Michael McGlothlin
wrote:
> Why include numbers at all? Some people only manipulate strings so why not
> leave numbers to a third-party library that might be better?
You can try, but I don't think sarcasm alone is going to get you there.
If you want to do somethi
Why include numbers at all? Some people only manipulate strings so why not
leave numbers to a third-party library that might be better? Or maybe we
should use a string type that randomly drops lowercase characters because
uppercase is good enough for many people. People that want to keep those
char
Jason, I agree. Although I didn't exactly make it explicit enough, that was
my basic reasoning.
On Tue, Oct 6, 2015, 14:03 Jason Orendorff
wrote:
> On Fri, Oct 2, 2015 at 6:37 PM, Alexander Jones wrote:
> > What do other languages do?
>
> Well, Python's standard library has both a `sum()` built
On Fri, Oct 2, 2015 at 6:37 PM, Alexander Jones wrote:
> What do other languages do?
Well, Python's standard library has both a `sum()` builtin and a
statistics module. They handle floating-point weirdness differently:
>>> sum([1.0, 1e18, -1e18])
0.0
>>> import statistics
>>> sta
+1 for operating on arrays, though. That's too common of a case for most of
this. Either that or a common helper function:
```js
function apply(xs, f) {
return f(...xs)
}
[1, 2, 3, 4]->apply(Math.sum)
```
(There is talk of changing the syntax and splitting up the proposal in
https://github.com
On Mon, Oct 5, 2015 at 2:58 PM Marius Gundersen wrote:
> Wouldn't it make sense to wait for the bind syntax [1] before introducing
> new methods that work on arrays?
>
The functions don't accept arrays or operate on arrays—they accept any
number of arguments (eg. Math.hypot, Math.min, Math.max)
Wouldn't it make sense to wait for the bind syntax [1] before introducing
new methods that work on arrays? That way it could be added to a standard
or non-standard module without altering either the Math object or the
Array/Iterator prototype. Something like this:
```
import {sum, mean} from "iter
We aren't really arguing whether this can be in a separate library; in
fact, it is probably implemented many times over in separate libraries. My
argument is more that there is a deficiency if this must be reimplemented
many times across those libraries. Another deficiency lies in the fact that
Mat
Am I the only one here wondering if at least most of this belongs in a
separate library, rather than JS core?
1. Most everyday programmers would be okay with this. 100% accuracy
isn't a requirement, but speed often is.
```js
Math.sum = (...xs) => xs.reduce((a, b) => a + b, 0);
Math.mean = (...xs)
On Thu, Oct 1, 2015 at 6:52 PM Eli Perelman wrote:
> Reviving this thread, doing any type of simple statistics is more verbose
> than it probably needs to be as calculating sums, averages, etc. makes most
> resort to Array reduction. I understand the need for methods such as
> `Math.hypot(...valu
Note that the theoretical O(n) isn't always a good unit of measurement for
practical speed. Having to keep extra precision variables, or having extra
operations inside the loop will seriously slow down the computation, while
keeping it O(n).
I'd prefer that Math.sum(a, b, c) == a + b + c. In pract
On 10/02/2015 16:37, Alexander Jones wrote:
Interesting. I still feel that these algorithms should be given their proper
names in a math library, because I would feel quite troubled if `Math.sum(a, b,
c) !== a + b + c`. Maybe I'm alone in this view, though. What do other
languages do?
On Frid
Interesting. I still feel that these algorithms should be given their
proper names in a math library, because I would feel quite troubled if
`Math.sum(a, b, c) !== a + b + c`. Maybe I'm alone in this view, though.
What do other languages do?
On Friday, 2 October 2015, Waldemar Horwat wrote:
> On
On 10/02/2015 13:30, Alexander Jones wrote:
I really don't think I'd want a basic `Math.sum(a, b, c)` meaning anything
other than `a + b + c`, i.e. `(a + b) + c`. We should all just come to terms
with the fact that floating point addition is not associative.
Or is there really some simple, O(n
I really don't think I'd want a basic `Math.sum(a, b, c)` meaning anything
other than `a + b + c`, i.e. `(a + b) + c`. We should all just come to
terms with the fact that floating point addition is not associative.
Or is there really some simple, O(n) algorithm to do a better (more
"careful") job?
In addition, using reduce just to sum array elements forces a function
execution for every element. May not be bad for a minimal count of
elements, but doing statistical work on larger collections would benefit
from having an optimized summation.
Eli Perelman
On Fri, Oct 2, 2015 at 3:23 PM, Walde
On 10/01/2015 23:10, Sebastian Zartner wrote:
While Math.sum() and Math.mean() currently don't exist, they can easily be
polyfilled:
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#Sum_all_the_values_of_an_array
for summarizing the values of an
While Math.sum() and Math.mean() currently don't exist, they can easily be
polyfilled:
See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce#Sum_all_the_values_of_an_array
for summarizing the values of an array and the following code for building
the aver
In case it didn't come across, this is the thread I'm reviving:
https://mail.mozilla.org/pipermail/es-discuss/2015-April/042732.html
Eli Perelman
Mozilla
On Thu, Oct 1, 2015 at 5:51 PM, Eli Perelman wrote:
> Reviving this thread, doing any type of simple statistics is more verbose
> than it pr
Reviving this thread, doing any type of simple statistics is more verbose
than it probably needs to be as calculating sums, averages, etc. makes most
resort to Array reduction. I understand the need for methods such as
`Math.hypot(...values)`, but for ECMAScript to evolve to be useful in
statistics
I've actually found this limit in the past [1] mostly for string operations
and I remember it was already discussed in here.
2048 was a safe bet for all browsers I could test those days, but it'b be
very nice if any generic function, accordingly with the environment
capabilities, could expose some
Just a note about the whole upper bounds on arguments thing
In V8’s case (per the comment regarding io.js), the maximum arguments count for
Function.prototype.apply/Reflect.apply/Reflect.construct is 0x80
(https://github.com/v8/v8-git-mirror/blob/81345f1a2cdceaee8c891fc7512ae671f171308e/src/
C. Scott Ananian wrote:
I'm just saying: it's not safe to spread an arbitrary array into
`arguments` unless the spec explicitly says that the number of
arguments is limited only by heap size (not stack size) or something
like that. The ES6 spec does not contain any such language.
We've talke
On Wed, Apr 29, 2015 at 12:56 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote:
> > I suppose it would be nice if JavaScript engines fell back to passing
> arguments on the heap to avoid this problem, but I don't think that's part
> of the ES6 spec. Am I mistake
@Allen: I guess that cloning the array into the arguments list is indeed
heavier than needed. So when large arrays are used, a method that works on
arrays will be better. But for small arrays of unknown size, spreading them
looks like a nice syntactical help.
@Scott: those functions are indeed int
On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote:
> ...
> I suppose it would be nice if JavaScript engines fell back to passing
> arguments on the heap to avoid this problem, but I don't think that's part of
> the ES6 spec. Am I mistaken?
that's an implementation detail. The ES spec. doesn
On Apr 29, 2015, at 9:04 AM, C. Scott Ananian mailto:ecmascr...@cscott.net>> wrote:
> Aren't there limits to the number of arguments you can pass to a ES function
> before getting a stack overflow?
Yup. For example WebKit limits to around 1. This protects our other stack
overflow detectio
Aren't there limits to the number of arguments you can pass to a ES
function before getting a stack overflow?
I've gotten in trouble trying to abuse the `arguments` array like this
before, for example `Math.max.apply(Math, someVeryLargeArray)`.
Empirically, with iojs 1.8.1:
```
> Math.max.apply(M
IMHO, there are still some rather basic Math functions missing in ES.
1. `Math.sum([value1[, value2[, value3[, ...)`
A Math.sum() function would mostly be handy thanks to the spread operator.
So you can sum a complete array. Being able to do
```
var sum = Math.sum(...arr);
```
would be so m
29 matches
Mail list logo
