Native Tensor support

kai zhu kaizhu256 at gmail.com
Sat Jan 27 08:11:33 UTC 2018


every numerical webapp has unique requirements/slop for dealing with NaN's and i'm skeptical you can create a generalized numpy-like library in javascript than can handle them all in a user-friendly way. you will usually have a easier time debugging and fixing NaN-issues using specialized-code you write yourself (with insight about your app's use-case, numerical-range, and user-inputs), rather than from naively applying textbook-formulas to some blackbox tensor-library.

i wrote a numerical finance chrome-app 6 years ago (unfortunately it stopped working last may when yahoo shutdown their historical-stock-quoting api):
https://chrome.google.com/webstore/detail/financejs/cmldinilpjimkpkdfmikeclmmbnjpdej <https://chrome.google.com/webstore/detail/financejs/cmldinilpjimkpkdfmikeclmmbnjpdej>

source code here: https://github.com/kaizhu256/chrome-financejs/tree/alpha/public/financejs <https://github.com/kaizhu256/chrome-financejs/tree/alpha/public/financejs>

it took historical stock-quotes from yahoo-finance, and fitted them against cosine-waves to see if there were any intrinsic periodicities in timeframes ranging from a few weeks to several decades.  yes it used a multi-dimensional array library (i followed numpy’s striding approach, to avoid copy-on-transpose), and could take integers and floats of various widths, which were not needed at all for the product.  the intention was to create a reusable library for other numerical projects, but in hindsight that was pretty naive of me.  the library turned out too complicated to configure for reuse (*surprise surprise* for a javascript newcomer then transitioning from python/c). if i could do it again, i would just “hardcode” alot of stuff and use lists of contiguous 1d Float64Array’s, which would reduce the code-bloat by 4x, not to mention saving me a bit of nan-related headaches from naively writing and applying generalized matrix-operations in my original library (numerical performance turned out to be a complete non-issue in the product).

also in javascript, its generally easier to reuse code from previous zero-config projects with lots of hardcoding and minimal abstraction, than from one that's overly-configured.  simply copy-paste the old code and grep-and-replace the hardcodes, rather than deal with any complicated config-tooling.

-kai


> On Jan 27, 2018, at 11:37 AM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 
> I'm speaking from the framework's side. Yes, I did gloss over certain complexities and constraints, but yes, it's almost there in practice.
> 
> 1. If they don't expose the node through a ref or something, and no event handlers exist, they could just assume (unsafely) you don't reference it, and act accordingly. Note that I'm speaking from the framework level, which can take liberties browsers can't.
> 2. I make the assumption you build change lists beforehand, and that resolves all dependencies first. And in general, once you figure out what changes need made, it doesn't actually matter as long as you unregister `blur`/etc. handlers that fire on removal before applying the change list.
> 3. Script elements execute async, so you could ignore order here.
> 4. For style elements and ref-accessible elements, you could still execute the changes in set slices, splitting on nodes/callbacks that require awareness of past effects. (This could just be a flag.) However, these are exceedingly rare.
> 
> On Fri, Jan 26, 2018, 23:18 Boris Zbarsky <bzbarsky at mit.edu <mailto:bzbarsky at mit.edu>> wrote:
> On 1/26/18 10:49 PM, Isiah Meadows wrote:
> > Applying DOM changes from a static change list is
> > an embarassingly parallel\* problem.
> 
> Only if you know there are no overlaps in terms of the nodes involved.
> And you ignore mutation events.  And you ignore the fact that mutation
> records expose your order of operations.  And you know that none of the
> insertions have immediate side-effects (e.g. none are <script> nodes).
> And your style system doesn't try to do style recomputation in certain
> ways.  And probably some other conditions that I'm forgetting.
> 
> -Boris
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180127/d7caa3c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-27 at 12.51.59 PM.jpg
Type: image/jpeg
Size: 101990 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180127/d7caa3c2/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-27 at 2.28.13 PM.jpg
Type: image/jpeg
Size: 107222 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180127/d7caa3c2/attachment-0003.jpg>


More information about the es-discuss mailing list