You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe I am saying blasphemous things, but wouldn't it be better for ndarray and ndarray-* related packages to reside under github.com/ndarrayjs org?
I mean it would be way better UX to have ndarray-related modules under the same roof and keep scijs for generic-type modules, for both who use ndarrays and who use generic scientific packages.
I tend to agree. Would love to clean house. Maybe time to tackle scijs/ndarray#18 then? Would also love to clean up and drop some of the lesser modules while we're at it.
Ooh. Good catch. ndarray-dtype would be good to really think through and work in, if applicable. I guess specifically I'm thinking of python's numpy.array([...], dtype='uint8') and astype that really make it quick and easy to work with types. Should think through common js use cases and whether the api can be streamlined at all.
Maybe I am saying blasphemous things, but wouldn't it be better for ndarray and ndarray-* related packages to reside under github.com/ndarrayjs org?
I mean it would be way better UX to have ndarray-related modules under the same roof and keep scijs for generic-type modules, for both who use ndarrays and who use generic scientific packages.
Especially the utility packages, like ndarray-pack, ndarray-fill, cwise-compiler, cwise-parser etc. - they have very little to do with science.
Focusing org on a single project seems to be a good practice in regl-project, gulp, d3 etc.
@rreusser @mikolalysenko @scijs/owners
The text was updated successfully, but these errors were encountered: