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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
