Something like https://github.com/Skinney/core/blob/master/src/Elm/JsArray.elm ? It's what is used as the basis for Arrays in 0.19. It is not planned to be opened for use outside of elm-lang/core, but if it fits your usecase better, I'm sure Evan would be interested in hearing about it.
(JsArray is a thin wrapper over javascript arrays. Any operation that modifies the underlying structure causes a complete copy, but get and folds are very fast. Slicing when start === 0 is still going to be faster using Elm Arrays as it is a tree structure. On the other hand, it should be fairly easy to create a "view" instead of slicing, but that might give you problems with space leaks.) tirsdag 21. november 2017 11.24.09 UTC+1 skrev Rupert Smith følgende: > > On Monday, November 20, 2017 at 5:29:25 PM UTC, Francisco Ramos wrote: >> >> Ultimately, I'd like to rewrite NumElm using the elm-ndarray. Not sure >> how I'm gonna do this without writing kernel code. Linear algebra >> operations such as Inverse, Pseudo-inverse, Singular value >> decomposition, Eigenvalues and eigenvectors, etc... I simply have no idea >> how I'm gonna implement this. Need to have a look at solutions in >> Haskell for inspiration. >> > > I suspect you are up against a tough impedance mismatch between immutable > arrays for functional languages, and fast flat arrays for pure number > crunching. > > The tree structured arrays for functional languages are designed to allow > a new version to be created from an existing array, without copying the > entire array. Well, a balance between copying the least amount whilst > keeping the tree fairly shallow for fast access. > > Arrays of floats for number crunching ideally just want to be stored flat > in RAM, so you can point an optimized for-loop at them or your GPU. > > You could also look at Java nio.Buffer for some inspiration? These allow > off-heap 'direct' buffers to be created, but have an interface on the Java > language side to manipulate them. You can for example take a 'slice' of > such a buffer, and it give you a so-called flyweight object as the result, > that is, a start offset and length into the original buffer, but sharing > the same data. 'slice' therefore is a very efficient operation. > > This scheme won't translate into immutable functional data structures > without modification. For example, to modify such a buffer in an immutable > way, would mean copying the entire thing. I just mention it as a possible > source of inspiration to help you think about your design. > > Perhaps this is already what you have in mind for ndarray? A structure > that is more efficient for your use case, but that is wrapped in an > immutable functional API to make it play nicely with the host language. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
