Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript for Data Science

js4ds.org

Post reply on HN
Print view View original

51–60 of 83 posts

Re: JavaScript for Data Science

#51

Post by spion »

mschuetz wrote: post #15
spion wrote: post #12

Earlier quoted context omitted.

Other than the fact we have BigInts now, we also have * tensorflowjs, which runs on GPUs https://www.tensorflow.org/js and * danfo, which aims to be a pandas equivalent for JS: https://danfo.jsdata.org/ Given the powerful interactive visualisation capabilities available in JS, its only a matter of time until JS becomes a serious contender IMO.

> Other than the fact we have BigInts now performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower.

That's typical with most JS features, it takes some time for engine performance optimizations to catch up with them. In this particular case I suppose things are moving slower than expected, but with demand increasing prioritization will take place.

Re: JavaScript for Data Science

#52

Post by felixfbecker »

mschuetz wrote: post #16
nosianu wrote: post #8

Earlier quoted context omitted.

> Numbers are 64bit floats only - no integers, no big numbers. That is not true. BigInt has been available for a bit already. MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Availability: https://caniuse.com/bigint I don't want to argue for or against using JS for "data science" (I myself used R for that but I use JS a lot for other things), just a clarification on this one concrete claim.

> That is not true. BigInt has been available for a bit already. performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower. What JS needs are 64 bit integer types, and some form of typing system that allows differentiating between various number types.

Genuine question: I imagine most data science things involve arrays of numbers, not just single numbers. JS has UInt8Array, i.e. it does kinda have integers if you want them in an array anyway. Can that speed things up?

Re: JavaScript for Data Science

#53

Post by spion »

mschuetz wrote: post #16
nosianu wrote: post #8

Earlier quoted context omitted.

> Numbers are 64bit floats only - no integers, no big numbers. That is not true. BigInt has been available for a bit already. MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Availability: https://caniuse.com/bigint I don't want to argue for or against using JS for "data science" (I myself used R for that but I use JS a lot for other things), just a clarification on this one concrete claim.

> That is not true. BigInt has been available for a bit already. performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower. What JS needs are 64 bit integer types, and some form of typing system that allows differentiating between various number types.

The JIT that understands what number type you want and switches between 31 bit ints and doubles when assumptions are violated without big performance loss. Something similar is likely possible with bigints and 64bit ints

Re: JavaScript for Data Science

#54

Post by lhnz »

danpalmer wrote: post #3

I don’t want to repeat the old and tired JavaScript hate, but this just isn’t a great idea. I’d suggest that there are 3 important primitives for data science: flexible numeric types, fast math/algorithm libraries, and data manipulation being easy. JavaScript doesn’t really have any of these. Numbers are 64bit floats only - no integers, no big numbers. There aren’t equivalents to Numpy/Pandas/Scikit Learn, and the la…

You should absolutely read "JavaScript and the next decade of data programming" by Ben Schmidt [1] before outright saying that it wouldn't be a great idea.

JavaScript does have integers (e.g. `Uint8Array`) and it also has big numbers (e.g. `BigInt`). It's true that there's not yet an equivalent to Numpy/Pandas/Scikit yet, but POCs show that it will be possible to create such a thing and that we will be able to use the WebGPU API to access higher performance than is available using Python [2].

I'm not saying that it will definitely happen, but why not?

[1] http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/

[2] https://github.com/milhidaka/webgpu-blas

Re: JavaScript for Data Science

#56

Post by talolard »

As a data scientist who does more frontend, I think this is a really valuable concept. Hello by users/stakeholders engage with our work is the way to push it forward in the org and a dash of frontend can do wonders for getting that message across. It’s wonderful that people are making resources about the frontend for data scientists

Re: JavaScript for Data Science

#57

Post by clircle »

jwilber wrote: post #48
danpalmer wrote: post #3

I don’t want to repeat the old and tired JavaScript hate, but this just isn’t a great idea. I’d suggest that there are 3 important primitives for data science: flexible numeric types, fast math/algorithm libraries, and data manipulation being easy. JavaScript doesn’t really have any of these. Numbers are 64bit floats only - no integers, no big numbers. There aren’t equivalents to Numpy/Pandas/Scikit Learn, and the la…

On point 3 - I had to implement a logistic regression model in js recently and implementing all of the required math methods (eg dot product, transpose, vectorized addition, etc.) were actually super easy with js’s functional array utilities.

js doesn't have a glm library?

Re: JavaScript for Data Science

#58

Post by ctidd »

genrez wrote: post #39
__jem wrote: post #33

Earlier quoted context omitted.

Not changing `this` is a huge benefit that shouldn't be ignored. Especially when you're programming in a more functional style, it makes sense to default to arrow functions because you never want to engage in `this` shenanigans anyway. So, yes, I'd say it's a pretty common idiom in the JS community to replace "normal" function declarations.

I agree that inheriting the `this` for arrow functions is beneficial. To me it seems like you would want to use the normal syntax for global functions for hoisting and to prevent unintentional re-definitions, the arrow functions where you would use lambda functions in other languages, and the class method syntax for methods. side-note: Most of my JS experience is writing userscripts for myself, so I definitely do my…

As a heads up since you mentioned "class method syntax", methods are one of the most important places to have lexical `this` binding in many scenarios.

Take the following example, which is a normal class method:

> alertSum() { alert(this.a + this.b); }

And here we have an arrow function used to create an instance method (just an arrow function assigned to a property on the instance):

> alertSum = () => { alert(this.a + this.b); }

Then let's say we want to pass the method directly as callback:

> this.button.addEventListener('click', this.alertSum)

The first example (class method syntax) won't have the necessary `this` context unless it has its context bound to the instance through `Function.prototype.bind`. There are other patterns to avoid this (e.g. wrapping all callbacks in arrow functions when passing them), but it's useful to consider that classes methods can easily create confusion because that's _exactly where_ someone more used to a different language may assume the `this` context is bound lexically.

Re: JavaScript for Data Science

#59

Post by genrez »

ctidd wrote: post #58
genrez wrote: post #39

Earlier quoted context omitted.

I agree that inheriting the `this` for arrow functions is beneficial. To me it seems like you would want to use the normal syntax for global functions for hoisting and to prevent unintentional re-definitions, the arrow functions where you would use lambda functions in other languages, and the class method syntax for methods. side-note: Most of my JS experience is writing userscripts for myself, so I definitely do my…

As a heads up since you mentioned "class method syntax", methods are one of the most important places to have lexical `this` binding in many scenarios. Take the following example, which is a normal class method: > alertSum() { alert(this.a + this.b); } And here we have an arrow function used to create an instance method (just an arrow function assigned to a property on the instance): > alertSum = () => { alert(this.a…

Excellent point! I can see that getting confusing quickly.

Edit: I was confused about how this could work, so I dug through [1] for a bit. It appears that for each object of that class created, an arrow function will be created on that object and its this will indeed be bound to the same scope that the constructor function is bound to. This is really cleaver and I applaud whoever thought it up!

It is interesting to note that this creates a new arrow function on each object as opposed to the normal definitions which create a single function which is stored in the prototype of the class. (its easier to check this in a browser's dev console then it is to decode the spec)

This would suggest that one should use different approaches for different types of objects: It makes sense to use arrow functions for "resource" or "actor" objects, of which there are few but they may have callback functions. It makes sense to use normal method definitions for "plain old data", of which there may be many, (which would make the arrow functions too expensive) but they should not have callback functions.

[1] https://tc39.es/proposal-class-fields/unified.html

Re: JavaScript for Data Science

#60

Post by [deleted] »

felixfbecker wrote: post #52
mschuetz wrote: post #16

Earlier quoted context omitted.

> That is not true. BigInt has been available for a bit already. performance-wise, BigInts are terrible. Tried to use them, made things about a hundred times slower. What JS needs are 64 bit integer types, and some form of typing system that allows differentiating between various number types.

Genuine question: I imagine most data science things involve arrays of numbers, not just single numbers. JS has UInt8Array, i.e. it does kinda have integers if you want them in an array anyway. Can that speed things up?

[deleted]
Post reply on HN