@Shimuuar Yep, I think what @adamConnerSax is mentionning is realizable via
foldOver http://hackage.haskell.org/package/foldl-1.4.5/docs/Control-Foldl.html#v:foldOver to which you give any lens/prism/traversal, and a Fold from http://hackage.haskell.org/package/foldl-statistics
(cc @MMesch didn't you use that pattern in the past?)
I think that’s all there is for an exact median but there are approximate methods eg https://github.com/tonyday567/online/blob/master/online/src/Online/Medians.hs#L23
hi, hugging face has released a new Rust implementation of their byte pair tokenizers: https://github.com/huggingface/tokenizers
they are looking for language binding contributions. Haskell bindings would be more than welcome. they would fill a gap we currently have with hasktorch where we work towards pre-trained Bert and gpt-2 models people can use in their projects
they are looking for language binding contributions. Haskell bindings would be more than welcome. they would fill a gap we currently have with hasktorch where we work towards pre-trained Bert and gpt-2 models people can use in their projects
last time i looked at hasktorch it was missing things (or at least i had the impression). I would prefer to migrate to hasktorch in the next months/years .. provided my supervisor is ok with that & i can train ppl. on the job with it.. ;)
But then there will maybe be more contributions from my side ..
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.