Native Tensor support

Robert Eisele robert at xarg.org
Sun Jan 28 13:27:29 UTC 2018


Q1: That's a good question. To me, tensors could have their own habitat 
within the JS scope, without handling existing data types, since they 
typically serve different purposes.

Q2: I don't quite get what you mean by kernel-like API. Could you go 
into more detail on that?

C1: Sure, that is what I said. It's easy to construct multi-dimensional 
arrays already, but neither is there a shortcut for such arrays, like in 
C++ with "new int[4][4][3]", nor is there a fast and parallel way of 
working with data in a certain dimension.

C2: Machine learning is just a momentary hype. Who knows what it will be 
in the next 5-10 years - nano*, quantum*, ... Whatever it is, the trend 
goes into the direction of calculations of high-dimensional data - and 
another trend is that all that will eventually land in the browser. So 
tensors as an abstract algebraic object right at the finger tips of a JS 
developer could facilitate all that.

I'm not sure if tensors are the best abstraction for DOM parallelism. 
Furthermore, I think static changes should not go beyond 2- or 3 
dimensional spaces. And as Boris said, it only works if one can make 
sure there are no overlaps.

Robert


Am 27.01.18 um 04:49 schrieb Isiah Meadows:
>
> Two questions:
>
> 1. Would APIs that operate on existing data types (rather than 
> tensors) work just as well?
> 2. Could there instead be a kernel-like API that could work on things 
> independently? Lower level APIs that enable equivalent high-level 
> constructs is a much better place to start.
>
> And two comments:
>
> 1. You could easily emulate 2D arrays by simply using 1D arrays and 
> storing data in row- or column-major order. This is pretty well-known 
> at this point, and is how C/C++ allocate multi-dimensional arrays 
> internally.
> 2. Data parallelization requires special consideration, and I can 
> assure you, machine learning isn't the only thing that could stand to 
> benefit from this. It needs to be broad enpugh that other non-data 
> applications can benefit from it. (Applying DOM changes from a static 
> change list is an embarassingly parallel\* problem. So anything that 
> could speed this up by a substantial bit could be infinitely useful to 
> anyone using Angular, React, Ember, or any other framework out there.)
>
> \* Yes, that's a technical term. Look it up on Wikipedia.
>
>


More information about the es-discuss mailing list