I'm steadily working towards what I informally call "haskformers"...
watch it happen here: hasktorch/hasktorch#269
watch it happen here: hasktorch/hasktorch#269
this is just a transformer language model (gpt-2 style) implementation.
later we want to be able to load hugging face transformers models and also use their tokenizers. hence the call for help
the PR got merged, https://hasktorch.github.io/hasktorch-0.2.0.0/html/Torch-Typed-NN-Transformer.html
next I'm going to set up the training
next I'm going to set up the training
@tscholak how complicated do you think wrapping the tokenizers will be? I never worked with bridging to rust from Haskell...
there's some old article on calling Rust from Haskell here: https://blog.mgattozzi.dev/haskell-rust/
whoever works on this, has to be ok with the cost of not working on something else. I don’t check that box at the moment
https://github.com/e-wrks/edh finally I can release this as a first version, the outcome is far beyond what I've imagined when I started working on it. anyway it reads the tape now :D
Based on how easy this looks https://github.com/aisamanra/rust-haskell-ffi and the few bits I've read on rust making it a goal to slot in for C FFI easily, knowing rust may even be optional.
I don't know how much demand there is. We can develop inline-rust instead of inline-c.
http://hackage.haskell.org/package/language-rust
https://hackage.haskell.org/package/inline-c
haskell-with-rust -(template haskell generates)-> haskell, rust and c
http://hackage.haskell.org/package/language-rust
https://hackage.haskell.org/package/inline-c
haskell-with-rust -(template haskell generates)-> haskell, rust and c
buecking @buecking reading whatever docs he can find
@buecking if you have questions, here or the gitter https://gitter.im/tweag/porcupine are good places :)
This seems like a crowd that could potentially find use for this new library that I created: https://github.com/lehins/Color
Let me know what you guys think.
Let me know what you guys think.
@GregorySchwartz
And most importantly one is capitalized and has American spelling , where the other one is named with lower case and is spelled in British English. :D
Color has quite a bit more functionality, more type safety and is much-much faster than colour. There is a benchmark section in the library in case you are curious to see for yourself. Also I couldn't find a repo where colour package is maintained, which I think is a serious drawback.And most importantly one is capitalized and has American spelling , where the other one is named with lower case and is spelled in British English. :D
Just as a sanity check I have tests that compare the values between the two libraries for the intersecting functionality.
Here..
ideally some cover-tree-algorithm .. ;)
welp ... i tried https://hackage.haskell.org/package/KdTree but it is painfully slow ... i would have to rewrite it (no bangs, no optimizations anywhere..)
Drezil, I've never tried but did you see https://izbicki.me/blog/fast-nearest-neighbor-queries-in-haskell.html ?
apparently the hackage version is deprecated though
after mike finished his phd (in 2015 or so) the project went dead anyway.
I have a crazy question for you guys. I'm trying to extract a color map, mapping a word to a color value, from this old book. I'm thinking maybe extract columns of pixels using JuicyPixels, then cluster them with K-means? Just a guess. How would you go about this, in terms of the Haskell libraries you'd use?
@JonathanReeve I can suggest using an array library
That is my suggestion, but I am a bit biased towards those libraries ;)
massiv: https://github.com/lehins/massiv for doing the processing, Color+massiv-io (https://www.stackage.org/haddock/nightly-2020-02-22/massiv-io-0.2.0.0/Graphics-ColorModel.html) packages for handling pixels in desired color models/spaces and then use massiv-io for reading/writing massiv arrays by the means of JuicyPixelsThat is my suggestion, but I am a bit biased towards those libraries ;)
ahh.. "barrier" is the keyword
@Drezil Checkout
Any time you call
scheduler package, see the section on nested parallelism: https://github.com/lehins/haskell-scheduler#nested-parallelismAny time you call
withScheduler it will not exit until all worker threads are done.
in the meantime i built a Work-stealing TQueue by myself ;)